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Chapter  1 

Introduction 


The  following  chapters  describe  the  work  of  the  Dependable  System  Architecture 
group  of  SRI  International’s  System  Development  Laboratory^  on  the  Secure 
Distributed  Transaction  Processing  (SDTP)  project.  Each  chapter  was  origi¬ 
nally  a  technical  report  or  article.  They  have  been  lightly  edited  —  for  example, 
notational  conventions  are  much  more  consistent  than  in  the  originals  but 
the  redundancy  that  allows  each  to  be  read  independently  of  the  others  has 
been  retained.  You  can  read  only  those  chapters  that  interest  you,  and  skip  the 
rest. 

Chapter  2  was  originally  published  in  the  proceedings  of  the  1997  IEEE 
Symposium  on  Security  and  Privacy,  held  in  Oakland,  CA  [27].  The  authors 
of  this  chapter  are  R.  A.  Riemenschneider,  Mark  Moriconi  (now  at  SecureSoft), 
Xiaolei  Qian  (also  at  SecureSoft),  and  Li  Gong  (now  at  JavaSoft),  It  describes 
the  goals  and  methodology  of  the  project,  and  explains  why  achieving  those 
goals  would  be  significant.  The  basic  idea  of  bridging  the  gap  between  theory 
and  practice  by  linking  a  high-level,  demonstrably  secure  system  model  to  a 
reference  implementation  by  refinement  steps  that  preserve  security  generated 
considerable  interest. 

Chapter  3  appeared  as  a  technical  report  [38]  by  R.  A.  Riemenschneider. 
It  provides  a  proof  of  the  model-theoretic  result  used  in  Chapter  2  to  prove 
refinement  steps  are  “faithful”,  and  thus  preserve  security  as  well  as  functional 
properties.  It  seems  unlikely  that  this  result  is  original.  But,  to  the  best  of  our 
knowledge,  a  proof  has  never  appeared  in  print.  Given  the  central  importance 
of  the  result  to  our  method  of  establishing  correctness,  we  wanted  to  make  it 
widely  available. 

Chapter  4  also  appeared  as  a  technical  report  [39]  by  R.  A.  Riemenschneider. 
It  introduces  an  alternative  method  of  proving  refinement  steps  are  faithful  that 
is  much  simpler  to  apply,  but  is  less  widely  applicable  than  the  original.  It 
also  contains  a  detailed  proof  that  one  of  our  standard  refinement  examples, 
replacement  of  a  dataflow  channel  between  two  functions  by  a  shared  variable 

^The  DSL  group  was  part  of  the  Computer  Science  Laboratory  prior  to  the  founding  of 
the  System  Development  Laboratory  this  year. 
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that  is  written  by  one  and  read  by  the  other,  faithfully  interprets  the  theory  of 
the  dataflow  structure  in  the  theory  of  the  shared  variable  structure,  using  the 
simplified  method. 

Chapter  5  is  the  last  in  the  series  of  technical  reports  by  R.  A.  Riemen- 
schneider  describing  the  method  for  showing  refinement  patterns  are  faithful, 
and  hence  security-preserving  [41].  It  is  primarily  devoted  to  arguing  that  our 
previous  proofs  established  only  the  faithfulness  of  particular  refinement  steps 
(i.e.,  instances  of  refinement  patterns),  and  not  the  faithfulness  of  the  gener¬ 
ally  applicable  pattern,  because  crucial  contextual  features  are  ignored.  It  is 
demonstrated  that  faithfulness  of  the  refinement  step  is  not  sufficient  to  guar¬ 
antee  faithfulness  of  the  general  pattern.  But  a  technique  for  converting  proofs 
of  “contextless”  refinement  steps  into  proofs  of  refinement  transformations  that 
can  be  applied  in  most  contexts  is  presented. 

Chapter  6,  also  by  R.  A.  Riemenschneider,  shows  how  refinement  patterns 
that  do  not  always  preserve  a  property  of  interest,  such  as  security,  can  be  used 
without  losing  the  correctness  guarantee  that  a  restriction  to  validated  refine¬ 
ment  patterns  automatically  provides.  This  flexibility  was  crucial  to  our  strategy 
of  basing  the  SDTP  derivation  on  our  (non-secure)  X/Open  DTP  derivation. 
(This  strategy  is  explained  in  more  detail  in  Chapter  7.)  We  had  established 
that  the  particular  refinement  steps  in  the  DTP  derivation  were  faithful,  but 
not  that  the  general  patterns  employed  were  always  faithful.  The  technique  de¬ 
veloped  in  Chapter  5  usually  guaranteed  faithfulness  of  the  corresponding  step 
in  the  SDTP  derivation,  but  occasionally  failed  to  do  so  because  contextual 
restrictions  were  violated.  The  basic  idea  behind  checking  refinement  steps, 
inspired  by  recent  work  on  proof-carrying  code,  is  to  refine  a  proof  of,  say,  ar¬ 
chitectural  security  properties  in  parallel  with  the  refinement  of  the  architecture 
itself.  If  the  refined  proof  of  the  security  of  the  more  abstract  architecture  can 
be  turned  into  a  proof  of  the  security  of  the  refined  architecture,  then  the  refined 
architecture  clearly  has  the  desired  security  property.  This  chapter  originally 
appeared  in  the  IFIP  volume  on  Software  Architecture  [40].  As  it  was  writ¬ 
ten  for  a  general  software  engineering  audience,  it  makes  fewer  demands  on  the 
reader’s  mathematical  skills  than  the  previous  three  chapters. 

Chapter  7,  by  Fred  Gilham,  R.  A.  Riemenschneider,  and  Victoria  Stavridou, 
was  presented  at  the  recent  World  Congress  on  Formal  Methods  (FM  ’99)  as  a 
case  study  in  architecture  verification.  It  describes  the  derivation  of  the  SDTP 
reference  implementation  from  the  abstract,  “secure  dataflow  style”  description 
of  the  SDTP  architecture,  and  provides  a  nice  summary  of  the  results  of  the 
project.  A  description  of  the  first  application  of  the  reference  implementation 
—  coordinating  access  to  distributed,  multilevel  law  enforcement  databases  — 
is  also  included. 

Finally,  Chapter  8,  a  paper  written  for  the  upcoming  Lisp  User  Group  Meet¬ 
ing  by  Fred  Gilham  and  David  Shih,  provides  more  detail  on  the  reference  im¬ 
plementation.  It  also  describes  the  two  applications  of  the  reference  implemen¬ 
tation,  the  law  enforcement  application  and  a  recent  application  that  accesses 
distributed,  multilevel  intrusion  detection  databases,  with  the  object  of  finding 
coordinated  patterns  of  attack  across  sites. 
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Chapter  2 


Secure  Software 
Architectures 

2.1  Chapter  Overview 

In  recent  years,  there  has  been  a  growing  demand  for  vendor-neutral,  open  sys¬ 
tems  solutions.  These  solutions  take  the  form  of  “open  software  architectures” 
that  represent  a  family  of  systems.  Open  architectures  are  critical  tools  for 
competitive  success  in  the  information  technology  industry  [29].  They  enable 
vendors  to  substantially  reduce  time-to-market  and  development  costs,  since 
they  do  not  have  to  provide  an  integrated  solution  in  the  context  of  a  bewil¬ 
dering  array  of  graphical  user  interfaces,  operating  systems,  and  connectivity 
schemes.  Moreover,  open  architectures  enable  consumers  to  have  confidence 
that  future  purchases  will  easily  integrate  with  existing  systems. 

Several  consortia  have  been  created  to  develop  open  software  architectures. 
For  example,  the  Object  Management  Group  (OMG),  which  consists  of  over 
600  companies,  has  developed  a  widely  accepted  architecture,  called  the  Com¬ 
mon  Object  Request  Broker  (CORE A),  that  allows  applications  to  communicate 
seamlessly  in  a  heterogeneous,  distributed  environment.  Interoperation  archi¬ 
tectures  also  have  been  developed  by  Sun  Microsystems  (Tooltalk),  Xerox  PARC 
(ILU),  Open  Software  Foundation  (DCE),  and  Microsoft  (OLE),  among  others. 

An  example  of  an  important  open  application  architecture  is  the  X/Open 
Distributed  Transaction  Processing  (DTP)  reference  architecture.  X/Open  DTP 
is  intended  to  standardize  the  interactions  and  communications  between  the 
components  of  the  3-tiered  client/server  model.  Figure  2.1  illustrates  a  repre¬ 
sentative  3-tiered  model  in  which  presentation  aspects  are  handled  by  “thin” 
clients,  business  logic  is  incorporated  in  the  transaction  processing  monitor  (e.g., 
BEA’s  Tuxedo"^^),  and  data/resource  management  is  the  responsibility  of  data 
servers  (e.g,,  Oracle  7,  IBM/DB2,  and  Sybase  11). 

The  X/Open  DTP  reference  architecture  allows  multiple  application  pro¬ 
grams  to  share  heterogeneous  resources  provided  by  multiple  resource  managers. 
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Figure  2.1:  3-Tiered  Client-Server  Architecture 
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and  allows  their  work  to  be  coordinated  into  global  transactions.  If  the  X/Open 
DTP  interfaces  (APIs)  are  adhered  to,  the  components  of  a  particular  DTP 
system  (namely,  every  application,  transaction  manager,  resource  manager,  and 
resource)  will  be  portable,  interchangeable,  and  interoperable. 

Tremendous  leverage  can  be  gained  by  incorporating  security  directly  into 
architectural  standards.  This  opportunity  has  been  recognized,  for  example,  by 
OMG  in  its  attempts  to  extend  CORBA  for  secure  object  access  and  communi¬ 
cation.  An  extension  of  X/Open  DTP  for  secure  transaction  processing  would 
enable  vendors  to  develop  single-  or  multilevel  products  with  little  or  no  concern 
about  the  security  of  the  overall  transaction  processing  system  in  which  they 
will  be  used.  Furthermore,  such  an  extension  would  allow  users  and  application 
vendors  to  concentrate  on  the  selection  of  components,  knowing  with  confidence 
that  the  overall  DTP  system  will  be  secure. 

The  benefits  of  a  secure  architectural  standard  can  be  realized  only  if  there 
is  high  and  justifiable  confidence  that  any  instance  of  it  satisfies  the  intended 
security  property.  An  erroneous  assumption  that  every  instance  of  an  X/Open 
DTP  architecture  properly  controls  access  to  protected  information  could  have 
serious  legal  and  business  consequences.  In  this  paper,  we  propose  a  formal 
approach  to  secure  architectures  that  involves  three  steps: 

1.  Formalization  of  the  system  architecture  in  terms  of  common  architectural 
abstractions. 

2.  Refinement  of  the  system  architecture  into  specialized  architectures,  each 
suitable  for  implementation  under  different  assumptions  about  the  security 
of  the  system  components.^ 

3.  Rigorous  proof  that  every  implementation  that  conforms  to  the  system 
architecture,  or  one  of  its  specializations,  satisfies  the  intended  security 
policy. 

Our  approach  is  made  difficult  by  the  dominance  of  informal  architectures^  and 
security  theories  that  are  difficult  to  connect  to  implementations.  Fortunately, 
we  can  overcome  these  difficulties  by  combining  recent  results  from  the  software 
research  community  [10, 12, 19,  25,  26]  with  well-known  results  from  the  security 
community. 

To  illustrate  our  approach,  we  present  excerpts  from  our  formalization  of  a 
secure  version  of  the  X/Open  DTP  standard  —  called  SDTP.  It  consists  mostly 
of  structural  information  involving  component  interfaces  and  the  connections 
among  them.  It  also  contains  causal  dependencies  between  certain  interfaces  and 
connections,  but  they  are  not  required  to  demonstrate  secure  access  control.  The 
access  control  property  was  chosen  because  it  is  well  understood  and  because  it 
is  important  in  the  commercial  and  the  military  sectors. 

1  Refinement  also  can  be  used  to  accommodate  different  computing  and  networking  envi¬ 
ronments,  but  that  is  not  the  focus  of  this  paper. 

^The  X/Open  DTP  standard  consists  of  approximately  500  pages  of  diagrams,  C  interfaces, 
and  English  explanations. 
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The  development  of  a  particular  secure  architecture  should  take  into  account 
two  important  observations,  both  of  which  are  illustrated  in  the  subsequent 
discussion  of  SDTP. 

1.  The  interplay  between  architectural  and  security  concerns  can  dramati¬ 
cally  affect  the  practicality  of  a  solution.  For  example,  the  obvious  way 
to  add  security  to  X/Open  DTP  has  the  consequence  that  vendors  must 
build  multilevel  components  —  even  though  they  are  not  security  experts 
and  may  want  to  target  larger,  single-level  markets. 

2.  Rather  than  modeling  a  system  as  a  single  architecture,  it  should  be  mod¬ 
eled  as  multiple,  but  related,  architectures  —  each  making  different  as¬ 
sumptions  about  the  security  of  the  system  components  and  the  protocols. 

2.2  Related  Work  in  Security 

There  are  two  main  challenges  in  developing  secure  (software  or  hardware)  sys- 
terns.  One  is  to  obtain  a  thorough  understanding  of  the  desired  security  prop¬ 
erties  and  the  relevant  (functional  and  non-functional)  properties  of  the  target 
system.  This  normally  calls  for  a  formal  model  of  the  system  together  with  se¬ 
curity  proofs,  often  given  in  some  mathematical  or  logical  language.  The  second 
challenge  is  to  assure  that  the  actual  system  implementation  realizes  the  more 
abstract  formal  model. 

The  research  community  has  spent  considerable  effort  on  the  first  of  these 
challenges.  The  security  properties  considered  include  non-interference,  infor¬ 
mation  flow,  and  composability,  with  system  models  built  using  traces,  CSP, 
and  other  formal  languages  [13,  21,  22,  23].  These  behavioral  models  are  far 
removed  from  the  actual  systems,  making  it  extremely  hard,  if  not  impossible, 
to  be  convinced  that  an  implementation  satisfies  the  security  properties  proven 
about  the  model. 

On  the  other  hand,  commercially  available  systems,  such  as  OSF’s  DCE 
1.1,  include  a  wide  range  of  security  functionalities,  such  as  authentication  and 
access  control.  But  these  architectures  cannot  be  linked  formally  to  a  solid 
theory  of  security  and,  given  the  overall  complexity  of  these  architectures,  it  is 
difficult  to  distill  whether  or  not  they  provide  the  desired  security  properties. 
The  same  observation  applies  to  uses  of  the  “reference  monitor”  concept  that 
was  popular  in  the  1980s.  Systems  designed  around  this  concept  could  not 
reliably  be  connected  to  implementations. 

A  middle  ground  between  abstract  mathematical  modeling  and  system-level 
analysis  can  be  seen  in  connection  with  the  Rampart  system  [37].  Rampart  is 
a  distributed  system  for  which  an  attempt  was  made  to  prove  that  it  satisfies 
certain  security  and  fault-tolerance  properties.  However,  the  proof  is  with  regard 
to  an  abstract  algorithmic  model,  which  again  suffers  from  the  difficulty  in 
relating  it  to  the  actual  implementation. 

A  successful  effort  to  connect  security  requirements  for  a  secure  gateway 
to  its  implementation  is  described  in  [33,  34].  A  convincing,  but  not  formal, 
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argument  is  made  that  the  connection  preserves  security.  The  argument  de¬ 
pends  on  the  use  of  architectural  elements  that  are  very  similar  to  those  used 
in  the  implementation.  Our  architecture  descriptions  [25,  26,  28]  are  more  gen¬ 
eral  in  three  important  ways.  First,  an  architecture  hierarchy  can  include  both 
horizontal  and  vertical  decomposition  (change  in  representation),  whereas  the 
gateway  development  involves  only  horizontal.  Second,  formal  mappings  be¬ 
tween  architectures  are  used  to  bridge  the  gap  in  vertical  hierarchies.  Third, 
our  architecture  definition  language  makes  it  easy  to  define  generic  architectures. 
These  three  capabilities  are  useful  in  defining  practical  architecture  standards, 
such  as  X/Open  DTP,  and  are  useful  in  architecting  any  large  system.  By  for¬ 
malizing  mappings  and  correctness  arguments,  we  can  prove  that  lower  levels 
in  a  vertical  hierarchy  —  ultimately,  the  implementation  preserve  security 
properties  proved  at  higher  levels. 

2.3  The  X/Open  DTP  Standard 

Distributed  transaction  processing  captures  the  core  activities  in  distributed  in¬ 
formation  systems,  namely,  the  interaction  between  applications  and  resources. 
Transactions  form  the  basis  of  such  interaction,  which  are  multiple  application 
programs  running  concurrently  and  accessing  shared  data  resources.  Distributed 
treinsaction  processing  is  ubiquitous  in  military  tind  commercial  applications, 
many  of  which  have  stringent  security  requirements. 

The  X/Open  DTP  standard  architecture  is  described  in  a  series  of  publi¬ 
cations  of  X/Open  Ltd.  [47,  49,  48,  46].  An  executable  prototype  of  the  DTP 
standard  appears  in  Luckham  et  al.  [19].  The  standard  describes  a  particular  set 
of  component  interfaces,  and  sequences  of  interactions  between  the  components. 
Components  may  be  various  application  programs,  resource  managers  (such  as 
databases,  file  systems,  or  mailers),  and  transaction  managers.  The  purpose  is 
to  define  a  standard  communication  architecture  through  which  multiple  appli¬ 
cation  prograims  may  share  resources  concurrently  by  organizing  their  activities 
into  transactions  which  appear  to  be  atomic.  Transactions,  which  may  execute 
concurrently,  can  contain  many  operations  on  resources.  Atomicity  means  that 
after  a  transaction  executes,  either  all  or  none  of  its  operations  take  effect. 

The  X/Open  description  is  informal,  consisting  of  English  text  together  with 
interfaces  given  in  the  C  programming  language.  The  important  features  of 
the  standard  are  (1)  the  interfaces,  (2)  the  architecture  (the  ways  of  connecting 
components  that  satisfy  the  standard),  and  (3)  the  protocols  (calling  sequences) 
for  using  the  interfaces.  The  calling  sequences  are  described  in  terms  of  a  single 
thread  of  control  and  C  function  calls.  Many  different  systems  with  various 
applications  and  resources  may  satisfy  this  standard.  Those  that  do  should  be 
easier  to  combine,  thus  promoting  the  goal  of  “open”  systems. 

A  version  of  the  X/Open  architecture,  shown  in  Figure  2.2,  consists  of  three 
types  of  components  —  one  application  program  (AP),  one  transaction  man¬ 
ager  (TM),  and  one  or  more  resource  managers  (RMs).  The  boxes  indicate  the 
component  interfaces,  and  the  lines  indicate  the  communication  between  them. 
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Figure  2.2:  X/Open  DTP  Reference  Architecture 


The  label  TX  indicates  a  complex  connection  and  protocol  defining  communi¬ 
cation  between  any  application  module  and  any  transaction  manager.  The  TX 
connection  contains  connections  between  functions  for  initiating  and  finalizing 
transactions.  Communication  is  always  initiated  by  the  application.  A  series 
of  calls  back  and  forth  continues  until  communication  is  completed.  Similar 
complex  connections  exist  between  the  application  and  every  resource  (the  AR 
connection),  and  between  the  transaction  manager  and  every  resource  manager 
(the  XA  connection).  The  XA  connection  involves  the  well-known  two-phase 
commit  protocol  for  ensuring  atomicity.  Much  of  this  activity  can  be  concurrent, 
and  many  transactions  may  take  place  at  once. 


2.4  Formal  Model  of  X/Open  DTP 

We  first  show  how  to  define  the  X/Open  DTP  interfaces,  components,  and 
wiring  using  an  architecture  definition  language  called  Sadl  [28].^  Then,  we 
describe  how  architectures  written  in  Sadl  can  be  translated  systematically 
into  logic.  All  the  proofs  in  this  paper  can  be  fully  formalized  in  terms  of  the 
logical  theories  that  result  from  the  translation. 

An  interface  is  defined  as  a  type  so  that  it  can  be  associated  with  more  than 
one  component.  For  example,  we  define  the  interface  for  transaction  managers 
as  follows. 

tm:  TYPE  <= 

MODULE 

EXPORTING  ALL 
BEGIN 

register:  AX_Register_Procedure 
[id:  X„Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

^Sadl  is  an  acronym  for  Structural  Architecture  Definition  Language. 
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unregister :  AX_Unregister .Procedure 
[rmid:  INT,  flags:  INT 
->  ret:  INT] 

begin:  TX.Begin.Procedure 
[  ->  ret:  INT] 
close:  TX.Close.Procedure 
[  ->  ret:  INT] 

commit:  TX.Commit .Procedure 
[  ->  ret:  INT] 

information:  TX.Inf o.Procedure 
[info:  TX.Inf o  ->  ret:  INT] 
open:  TX.Open.Procedure 
[  ->  ret:  INT] 

rollback:  TX.Rollback.Procedure 
[  ->  ret:  INT] 

END 

This  declaration  says  that  every  object  of  type  tm  is  a  module  containing  a 
definition  of  the  procedures  register,  unregister,  begin,  and  so  on,  used  in 
the  X/Open  specification  of  the  TX  interface.  For  example,  begin  is  declared 
to  be  a  TX-Begin-Procedure,  which  guarantees  that  it  has  an  appropriate  “se¬ 
mantics”  relative  to  its  role  in  the  protocol.  TX_Begin_Procedure  is  declared 
elsewhere  to  be  a  subtype  of  Procedure. 

As  an  example  of  a  more  complex  interface,  consider  the  definition  of  the 
application  interfaces,  which  must  allow  for  an  arbitrary  number  of  resources. 

ap:  TYPE  <= 

MODULE 

[«  ap.inl(i):  r.type(i) 

|(i:  NAT)  i  <  n  » 

->  «  ap.outl(i):  q.type(i) 

|(i:  NAT)  i  <  n  »] 


This  declaration  says  that  an  object  of  type  ap  is  a  module  with  n  input  ports 
(n  is  the  number  of  resource  managers  in  the  system  being  specified)  and  n 
output  ports.  The  type  of  the  i-th  input  port,  ap-inl(i),  is  r-type(i),  where 
r-type  has  been  declared  to  be  a  function  from  non-negative  integers  less  than 
n  to  subtypes  of  the  type  ar_resources  of  data  sent  from  the  RMs  to  the  AP. 
Similarly,  the  type  of  the  i-th  output  port,  ap-outl(i),  is  q.type(i),  where 
q.type  has  been  declared  to  be  a  function  from  non-negative  integers  less  than 
n  to  subtypes  of  the  type  ar_requests  of  data  sent  from  the  AP  to  the  RMs. 

The  declaration  of  a  resource  manager,  denoted  by  the  rm  type,  contains 
procedure  calls,  as  in  the  tm  declaration,  and  ports,  as  in  the  ap  declaration. 
Since  an  instance  of  DTP  can  contain  an  arbitrary  number  of  resources,  the  type 
rms  is  used  to  denote  the  union  of  an  arbitrary  number  of  resource  managers. 
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To  define  a  component,  we  simply  declare  an  instance  of  an  interface  type. 
The  declarations 

the.ap:  ap 
the_rins:  rms 
the^tm:  tm 

define  the  three  components  in  X/Open  DTP. 

The  interfaces  of  these  components  are  wired  together  by  constraints  associ¬ 
ated  with  the  AR,  XA,  and  TX  connections.  Here  is  a  representative  constraint 
on  the  TX  connection. 

tx_l:  ASSERTION  = 

Called.From (the^tm . begin ,  the_ap) 

says  that  the  procedure  begin  of  the  TX  protocol  declared  in  the_tm  is  called 
by  the-ap.  The  XA  interface  definition  consists  of  twelve  assertions  that  are 
similar,  except  that  they  are  general  so  as  to  apply  to  all  RMs.  An  example  is 

xa_l:  ASSERTION  = 

(FORALL  y:  rm) 

Called^FromCthe.tm. register ,  y) 

The  AR  interface  specification  is  more  abstract,  since  it  is  described  in  terms 
of  a  general  dataflow  connection  w^hich  need  not  be  implemented  as  a  procedure 
call.  The  assertion 

ar.l:  ASSERTION  = 

(FORALL  i:  NAT  I  i  <  n) 

(EXISTS  c:  Channel [q^type(i)]) 

Connects(c,  the_ap.ap_outl(i) , 
the.rms . rm_inl (i) ) 

says  that,  for  every  RM  index  i,  there  is  a  dataflow  channel  c  w'hich  carries  the 
appropriate  subtype  of  ar -requests  from  the  i-th  output  port  of  the.ap  to 
the  input  port  of  the  i-th  RM  in  the  collection  of  all  RMs,  the  jrms.  A  similar 
assertion  characterizes  the  flow  from  the  RMs  to  the  AP . 

Sadl  specifications  can  be  translated  systematically  into  logic,  allowing  us 
to  regard  architectures  as  logical  theories.  As  an  illustration,  consider  the  dec¬ 
laration 

begin:  TX_Begin_Procedure 
[  ->  ret:  INT  ] 

that  appears  in  the  tm  type.  It  is  translated  into 
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Vx  [TM(x)  3yTX-Begin>Procedure(y,x)] 

VxVy  [TM(x)  A  TX.Begin_Procedure(y,x) 

3z  Return_Parameter(z,  y)  ] 

VxVyVzVw 

[TM(x)  ATX-Begin-Procedure(y,x) 

A  Return_Parameter(z,  y) 

A  Integer(w) 

— y  May>Hold_Value,On_Return(z,  w)  ] 

This  says  that  every  transaction  manager  has  a  begin  procedure,  that  every  be¬ 
gin  procedure  has  a  return  parameter,  and  that  the  value  of  a  begin  procedure’s 
return  parameter  can  be  an  integer. 

Among  the  assertions  that  define  the  TX  interface  is 

Called_From(the„tin. begin ,  the.ap) 

which  can  be  translated  to 


Vx  [TX-Begin_Procedure(x,  the-.tm) 

3y  [CalL5ite(y,x) 

A  Location  (y,the_ap)  ]  ] 

This  says  that  every  TX  begin  procedure  is  called  from  a  site  located  in  the 
application. 

Translation  to  logic  is  essential  for  complicated  arguments,  such  as  the  rela¬ 
tive  correctness  proofs  of  Section  2.6,  and  when  fully  formalized  arguments  are 
required.  But  often,  simpler  results  can  be  directly  established  by  reasoning  in 
terms  of  Sadl  specifications.  The  next  section,  which  proves  the  security  of 
alternative  DTP  architectures,  illustrates  this  kind  of  rigorous  informal  reason¬ 
ing. 


2.5  Secure  DTP  Architectures 

Suppose  that  we  want  to  enforce  the  multilevel  security  (MLS)  policy  in  the 
DTP  architecture.  A  standard  model  of  the  MLS  policy  is  the  Bell-LaPadula 
model  [16].  Given  a  set  of  subjects  each  with  an  attached  clearance  level,  and 
a  set  of  objects  each  with  an  attached  classification  level,  the  model  ensures 
that  information  does  not  flow  downward  in  a  security  lattice  by  imposing  the 
following  requirements. 

•  The  Simple  Security  Property.  A  subject  is  allowed  a  read  access  to 
an  object  only  if  the  former’s  clearance  level  is  identical  to  or  higher  than 
the  latter’s  classification  level  in  the  lattice. 
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•  The  ★-Property.  A  subject  is  allowed  a  write  access  to  an  object  only 
if  the  former’s  clearance  level  is  identical  to  or  lower  than  the  latter’s 
classification  level  in  the  lattice. 

In  terms  of  the  DTP,  a  subject  might  be  a  user  invoking  an  application  or 
a  transaction  manager,  and  an  object  could  be  any  data  item  in  a  resource. 
We  say  a  component  in  DTP  is  MLS,  if  input  and  output  of  that  component 
are  properly  labeled  with  security  levels,  and  the  component  enforces  the  MLS 
policy  internally.  Similarly,  the  DTP  architecture  is  MLS,  if  it  enforces  the  MLS 
policy. 

Notice  that  the  MLS  policy  regulates  the  communication  between  the  ap¬ 
plications  and  the  resources,  which  is  application-specific  and  not  part  of  the 
DTP  standard.  It  is  not  obvious  how  the  MLS  policy  can  be  enforced  while  still 
maintaining  plug-and-play. 

A  naive  approach  is  illustrated  in  Figure  2.3,  where  each  (non-MLS)  appli¬ 
cation  or  resource  is  wrapped  by  an  MLS  wrapper,  which  together  enforce  the 
MLS  policy  at  the  interface.  This  approach  suffers  from  at  least  three  problems. 

•  High-assurance  technology  does  not  yet  exist  that  allows  a  non-MLS  com¬ 
ponent  (application  or  resource)  to  be  wrapped  to  enforce  the  MLS  policy, 
especially  when  the  component  contains  untrusted  code. 

•  Even  if  an  MLS  wrapper  technology  did  exist,  the  enforcement  of  the  MLS 
policy  by  a  wrapper  is  most  likely  dependent  on  the  application-specific 
internee  of  the  underlying  component,  w^hich  destroys  the  plug-and-play 
benefit  of  a  standard  architecture. 

•  The  alternative  is  to  require  that  vendors  provide  MLS  components,  which 
would  have  significant  drawbacks:  reduced  time-to-market,  stiff  perfor¬ 
mance  penalties,  and  increased  development  costs. 

Given  the  fact  that  most  of  the  COTS  and  legacy  components  available  today 
are  not  MLS,  our  strategy  is  therefore  to  develop  not  one  but  several  secure 
DTP  standards,  each  geared  toward  a  particular  configuration  of  applications 
and  resources.  In  the  remainder  of  this  section,  we  consider  three  possible 
configurations. 

The  simplest  configuration  is  when  the  application  and  all  the  resources  are 
single-level  and  are  at  the  same  level,  as  shown  in  Figure  2.4.  The  DTP  standard 
does  not  need  any  extension  to  enforce  the  MAC  policy,  since  there  cannot  be 
any  downward  (or  cross-level)  information  flow  in  the  security  lattice, 

A  second  possible  configuration  is  when  the  application  and  all  the  resources 
are  single-level  but  perhaps  at  different  levels,  as  shown  in  Figure  2.5.  To 
enforce  the  MAC  policy,  the  AP  and  the  RMs  cannot  directly  communicate 
with  each  other.  Instead,  communication  has  to  be  filtered  by  an  MLS  filter, 
which  regulates  every  access  by  the  AP  to  the  RMs  to  ensure  the  simple  security 

^We  concern  ourselves  only  with  the  two  properties  of  the  Bell-LaPadula  model,  not  with 
issues  such  as  object  reuse  or  covert  channels. 
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Figure  2.3:  Secure  DTP  with  MLS  Wrappers 


property  and  the  ★-property  of  the  Bell-LaPadula  model.  The  TM  is  required 
to  be  MLS  since  it  interacts  with  components  at  different  levels. 

For  this  scenario,  the  DTP  standard  needs  to  be  extended  as  follows.  The 
begin  and  register  procedure  calls  in  the  TM  interface  are  extended  with  a  label 
parameter  to  indicate  the  level  of  the  RM  or  AP  caller. 

tm:  TYPE  <= 

MODULE 

EXPORTING  ALL 
BEGIN 

register:  AX_Register ^Procedure 
[id:  X.Id,  rmid:  INT, 
flags:  INT, 
lb:  LABEL 
->  ret:  INT] 

begin:  TX^Begin.Procedure 
[lb:  LABEL  ->  ret:  INT] 


END 

The  security  of  the  resulting  DTP  architecture  with  respect  to  the  MLS 
policy  can  be  shown  as  follows.  Suppose  that  the  AP  is  low  and  a  particular 
RM  r  is  high.  Let  us  consider  the  simple  security  property  of  the  Bell-LaPadula 
model.  The  only  way  that  AP  can  read  data  in  r  is  through  either  the  TM  or 
the  filter.  Since  communication  is  secure,  any  data  from  r  to  the  TM/filter  will 
be  properly  labeled  high.  Since  the  TM/filter  is  MLS,  it  cannot  pass  high  data 
to  the  low  AP,  meaning  that  AP  cannot  read  data  from  r.  Similarly  we  can 
argue  that  the  ★-property  of  the  Bell-LaPadula  model  holds. 
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Figure  2.4:  Secure  DTP  with  Same-Level  AP  and  RMs 


The  most  complicated  configuration,  shown  in  Figure  2.6,  is  when  the  appli¬ 
cation  and  the  resources  are  multilevel,  in  contrast  to  the  wrapped  components 
in  Figure  2.3.  The  AP  and  the  RMs  can  directly  communicate  with  each  other, 
since  they  are  capable  of  handling  data  at  different  levels.  Again,  the  TM 
should  be  MLS  as  well.  Conceptually  every  multilevel  connection  can  be  viewed 
as  consisting  of  multiple  single-level  connections,  one  for  each  level. 

The  DTP  standard  needs  to  be  extended  as  follows.  Every  AP  and  RM 
interface  is  extended  with  a  label-range  parameter  to  indicate  the  range  of  levels 
of  the  AP  and  RM,  respectively.  Like  before,  the  register  and  begin  procedure 
calls  in  the  TM  interface  are  extended  with  a  label  parameter  to  indicate  the 
level  of  the  RM  or  AP  caller.  In  addition,  there  is  a  constraint  requiring  that 
there  is  a  register  procedure  call  for  every  level  in  every  RM’s  range.  A  similar 
constraint  is  needed  for  the  begin  procedure  call. 

rm:  TYPE  <= 

MODULE 

EXPORTING  ALL 
BEGIN 

low :  LABEL 
high :  LABEL 

label^order:  ASSERTION  = 
low  <=  high 


END 

tm:  TYPE  <= 
MODULE 

EXPORTING  ALL 
BEGIN 
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Figure  2.5:  Secure  DTP  with  Single-Level  AP  and  RMs 


register (lb:  LABEL): 
AX_Register .Procedure 
[id:  X.Id,  nnid:  INT, 
flags:  INT 
“>  ret ;  INT] 


END 

the_tiii:  tm 

rins_label:  ASSERTION  = 

(FQRALL  x:  rm) (FORALL  y:  LABEL) 

[x.low  <=  y  AND  y  <=  x.high 
=>  Called.From 

(the.tm. register (y) ,  x)] 

It  is  straightforward  to  prove  the  security  of  this  architecture.  Since  every 
connection  is  single-level,  and  every  component  is  MLS,  a  component  cannot 
send  data  through  a  connection  if  the  level  of  the  data  is  different  from  that  of  the 
connection.  Since  communication  is  secure,  any  data  received  via  a  connection 
will  have  the  same  level  as  that  of  the  connection.  Given  that  every  component 
properly  enforces  the  two  properties  of  the  Bell-LaPadula  model,  so  does  the 
resulting  architecture. 
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Figure  2.6:  Secure  DTP  with  Multilevel  AP  and  RMs 


2.6  Relating  the  SDTP  Architectures 

We  can  relate  the  four  SDTP  architectures  by  defining  a  general  model  for 
SDTP  and  then  proving  that  each  of  the  four  SDTP  architectures  ia  a  correct 
specialization  of  it. 

2.6.1  Correctness  Criterion 

The  traditional  interpretation  of  relative  correctness  is  not  strong  enough  for 
our  purposes  because  it  only  requires  that  the  concrete  architecture  extend  the 
abstract  architecture.  Hence,  a  low-level  architecture  can  introduce  properties 
that  contradict  the  higher-level  architecture,  which  can  lead  to  a  violation  of 
security  properties  in  the  reference  architecture.  For  example,  consider  the  proof 
in  Section  2.5  that  the  SDTP  architecture  in  Figure  2.5  is  secure.  The  proof 
critically  depends  on  the  fact  that  the  only  way  that  AP  and  RMs  communicate 
is  through  either  the  MLS  TM  or  the  MLS  filter.  The  low-level  architecture  can 
extend  this  by  including  a  new  non-MLS  flow  from  AP  to  an  RM.  This  extended 
low-level  architecture  by  definition  “implements”  the  high-level  architecture,  but 
the  extension  clearly  violates  multilevel  security  requirements. 

We  have  developed  a  new  correctness  criterion  for  architectures  in  which 
a  concrete  architecture  implements  exactly  the  abstract  architecture,  no  more 
and  no  less  [26].  In  other  words,  a  security  hole  that  does  not  exist,  with 
respect  to  a  given  security  policy,  in  the  abstract  architecture  will  not  come 
into  existence  in  any  concrete  architecture.  To  use  our  earlier  example,  under 
our  new  correctness  criteria,  it  is  possible  to  ensure  that  no  new  data  flow  can 
be  introduced  in  the  low-level  architecture.  That  is,  if  flow  from  B  to  C  exists 
in  the  low-level  architecture,  then  this  flow  must  already  exist  in  the  high-level 
architecture,  either  as  a  direct  or  indirect  flow.  This  flow  thus  implies  that  the 
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high-level  design  is  not  secure  and  should  be  modified.  Conversely,  if  we  can 
prove  that  the  high-level  architecture  is  secure,  then  we  can  rest  assured  that 
the  mapped  low-level  architecture  is  also  secure. 

To  formalize  this  notion,  we  first  need  to  make  explicit  an  important  com- 
pleteness  assumption  about  architectures.  In  particular,  we  assume  that  an 
architecture  contains  all  components,  interfaces,  and  connections  intended  to 
be  true  of  the  architecture  at  its  level  of  detail.  If  a  fact  is  not  explicit  in  the 
architecture,  or  deducible  from  it,  we  assume  that  it  is  not  intended  to  be  true 
of  the  architecture.  In  general,  an  architecture  (whether  static  or  dynamic)  can 
contain  an  unbounded  number  of  facts. 

Formally,  we  need  to  prove  that  two  architectures,  represented  as  theories, 
are  correct  with  respect  to  an  interpretation  mapping  between  them  and  the 
completeness  assumption.  Let  0  and  0'  be  theories  associated  with  an  abstract 
and  a  concrete  architecture,  respectively.  Let  y  be  an  interpretation  mapping 
from  the  language  of  0  to  the  language  of  &.  For  every  sentence  (p,  mapping 
y  is  a  theory  interpretation  provided 

if  ip  £  0  then  y{<p)  G  & 

This  is  the  usual  definition  of  correctness. 

Since  a  given  architecture  is  assumed  to  be  complete  with  respect  to  its  level 
of  detail,  we  additionally  require  that  the  concrete  architecture  add  no  new  facts 
about  the  abstract  architecture.  To  prove  this,  we  must  additionally  show  that 

if  (p  ^  0  then  y{p)  ^  & 

in  which  case,  is  a  faithful  interpretation.  This  says  that,  if  a  sentence  is  not 
in  the  abstract  theory,  its  image  cannot  be  in  the  concrete  theory.  (Observe 
that  0^  is  a  conservative  extension  of  0  provided  the  identity  map  faithfully 
interprets  0  in  0'.)  Theory  0'  can  contain  sentences  not  in  y[0]  —  i.e.,  new 
facts  about  the  architecture  not  included  in  0  —  but  these  facts  must  not  have 
any  consequences  expressible  in  the  language  of  0. 

2.6.2  The  General  Model 

Let  the  AP,  TM,  and  RMs  be  represented  as  functional  components  with  labeled 
input  and  output  ports  connected  by  secure  channels.  More  specifically,  we 
require  that 

•  Data  have  associated  security  levels^  which  are  collections  of  authentica¬ 
tion  data  and  credentials  that  characterize  the  data's  security  standing. 
Thus,  a  datum  can  be  thought  of  as  a  value  together  with  a  security  label 
that  determines  its  level. 

•  The  ports  where  the  data  is  supplied  and  received  have  associated  clear¬ 
ance  levels. 

•  The  channels  that  carry  data  also  have  associated  clearance  levels. 
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The  connections  in  the  general  model  that  represent  the  AR,  XA,  and  TX 
interfaces  are  subject  to  three  constraints. 

1.  An  input  port  can  receive  data  only  if  its  clearance  level  dominates  the 
data’s  security  level. 

2.  An  output  port  can  supply  data  only  if  its  clearance  level  is  dominated  by 
the  data’s  security  level. 

3.  A  channel  can  carry  data  only  if  its  clearance  level  dominates  the  data’s 
security  level. 

If  these  constraints  are  satisfied,  we  may  refer  to  ports  as  secure  ports  and  to 
channels  as  secure  channels. 

2.6.3  Example  Proof  Relating  Two  Architectures 

It  can  be  proven  that  the  four  SDTP  architectures  correctly  implement  the 
general  model.  In  this  section,  we  focus  on  the  most  complicated  proof,  which 
involves  Figure  2.4.  Specifically,  we  prove  that  a  combination  of  writing  and 
reading  data  that  is  mediated  by  the  MLS  filter  correctly  implements  secure 
dataflow. 

This  requires  showing  that  a  mapping  ^  from  the  language  of  secure  dataflow 
to  the  language  of  mediated  reading  and  writing  is  a  faithful  interpretation  of 
the  theory  of  secure  dataflow,  0,  in  the  theory  of  mediated  reading  and  writing, 
&.  The  interesting  predicates  in  the  language  of  secure  dataflow  are 

•  Secure.Channel(x),  which  means  that  x  is  a  secure  channel, 

•  Connects(x,y,2),  which  means  that  secure  channel  x  connects  secure  out¬ 
put  port  y  to  z, 

•  Can-Carry (x,  y),  which  means  that  secure  channel  x  can  carry  datum  y  (i.e., 
that  the  datum  contains  an  appropriate  type  value  and  has  a  security  level 
no  higher  than  the  clearance  level  of  the  channel), 

•  Clearance. Level(x,  y),  which  means  that  either  the  security  label  x  is  greater 
than  or  equal  to  the  clearance  level  of  y,  when  y  is  either  an  output  port 
or  channel,  or  the  security  label  x  is  less  than  or  equal  to  the  clearance 
level  of  y,  when  y  is  either  an  input  port,  and 

•  Security- Level(x,y),  which  means  that  either  the  security  label  x  is  less 
than  or  equal  to  the  security  level  of  the  datum  y, 

together  with  a  lattice  ordering  <  of  security  labels. 

The  predicates  of  interest  in  the  language  of  MLS-mediated  reading  and 

writing  are 

•  MLS_Filter(x),  which  means  that  x  is  an  MLS  filter. 
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•  Secure^Write(x,  y),  which  means  that  x  is  a  call  site  that  performs  a  secure 
write  to  y, 

•  Secure-Read (x,y),  which  means  that  x  is  a  call  site  that  performs  a  secure 
read  of  y, 

•  Filter-Passes(x,y),  which  means  that  MLS  filter  x  can  pass  datum  y  (i.e., 
that  the  datum  contains  an  appropriate  type  value  and  has  a  security  level 
no  higher  than  the  clearance  level  of  the  secure  read  and  no  lower  than 
the  clearance  level  of  the  secure  write), 

•  Clearance.  Level (x,  y) ,  which  has  the  same  meaning  as  in  the  secure  dataflow 
language,  and 

•  Security.  Level (x,y),  which  also  has  the  same  meaning  as  in  the  secure 
dataflow  language, 

together  with  a  lattice  ordering  of  security  labels  which  is  also  called  <. 

The  relevant  part  of  can  be  defined  as  follows: 

Secu  re.Cha  n  nel  (x) ) 

=  MLS-Filter(c/(x)) 

J^(Connects(x,y,z)) 

=  [Secure_Write(J^(y),c/(x)) 

A  Secure_Read(c/(z),  J^(x))] 

c/(Can_Carry(x,y)) 

=  Filter_Passes(c/(x),  ./(y)) 

./(Clearance.  Level  (x,  y)) 

=  Clearance.  Level(c/(x),  ^(y)) 

/(Security.  Level(x,  y)) 

=  Security.  Level  (/(x),  /(y)) 

<  y)  =  [^(x)  <  Ay)] 

together  with  clauses  that  map  each  abstract-level  secure  channel  to  a  concrete- 
level  mediated  read  and  write  combination. 

Note  that  /  naturally  determines  a  mapping  /  ^  from  structures  of  the 
concrete  language  to  structures  of  the  abstract  language.  Given  a  structure 
Tl'  of  the  concrete  language,  /^(QTt')  is  defined  as  follows.  The  universe  of 
is  the  same  as  |93T'|,  the  universe  of  971'.  If  /  maps  atomic  formula 
P(xi ,  X2, . . .  ,  Xn)  to  concrete  formula  (p,  then  the  extension  of  P  in  /  ^(971')  is 
the  set  of  n-tuples  from  the  universe  of  971'  that  satisfy  p.  That  is,  the  extension 
of  P  in  /^(97l')  is 


{(mi,m2,. ..  ,mn)  €  |97l'|”: 

971'  1=  v?[xi/mi,X2/m2,...  ,Xn/mn]} 
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Showing  that  is  a  theory  interpretation  is  simply  a  matter  of  formally 
deriving  the  concrete  level  interpretation  of  each  abstract  level  axiom  from  the 
concrete  level  axioms.  For  example,  the  image  of  the  security  constraint 

VxVyVzVw 

[Secure_Channel(x) 

A  Clearance.  Level(x,  y) 

A  Datum(z) 

A  Security.  Level(z,  w) 

A  Can_Carry(x,z) 

->2<y] 

must  be  derived  from  the  axioms  describing  the  properties  of  the  filter.  This  is 
straightforward. 

To  show  that  ^  is  faithful,  we  will  describe  a  mapping  Jf  from  models  of 
abstract-level  theory  Q  to  models  of  concrete-level  theory  &  such  that,  for  every 
model  Tl  of  0,  is  isomorphic  to  9H.  The  faithfulness  of  y  follows, 

by  the  model-theoretic  result  cited  in  [26]. 

As  the  definition  of  suggests,  the  only  difficulty  in  “inverting”  the  inter¬ 
pretation  is  handling  the  equation  for  Connects.  But  is  it  easy  to  see  that  letting 
the  extension  of  Secure.Read  in  be 

{(mi, m2)  6  for  some  m3  in  \DJl\, 

Tl  1=  Connects(xi,X2,X3)[xi/m2,X2/m3,X3/mi]} 

and  letting  the  extension  of  Secure.Write  in  J{dyi)  be 

{(mi, m2)  e  for  some  m3  in  |QJt|, 

Tl  1=  Connects(xi,X2,X3)[xi/m2,X2/mi,X3/m3]} 

will  yield  the  required  structure. 


2.7  Chapter  Summary 

We  have  combined  results  from  the  softw^are  and  security  research  communities 
to  form  a  new  methodology  for  the  construction  of  secure  architectures.  The 
method  involves  the  formalization  of  a  system  architecture  with  security  mecha¬ 
nisms  embedded  directly  in  the  architecture.  More  specifically,  the  mechanisms 
are  intended  to  provide  secure  access  control  as  defined  by  the  Bell-LaPadula 
model  (the  simple  security  property  and  the  ^property).  A  proof  about  the 
security  of  a  system  implementation  is  performed  by  reasoning  about  its  ar¬ 
chitecture.  If  an  architecture  is  secure,  every  valid  instance  of  it  is  secure. 
Architecture  instantiation  is  equivalent  semantically  to  theory  instantiation. 

An  important  contribution  of  our  work  is  the  modeling  of  a  system  in  terms 
of  multiple  secure  architectures  that  are  related  by  formal  mappings.  The  ar¬ 
chitectures  may  represent  both  horizontal  and  vertical  decompositions.  Proper 
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application  of  our  modeling  technique  enables  vendors  to  develop  single-  or 
multilevel  products  with  little  or  no  knowledge  about  the  overall  application. 
Similarly,  customers  can  select  single-  or  multilevel  components,  knowing  with 
confidence  that  the  security  of  the  overall  system  will  be  intact.  An  example 
of  this  was  seen  in  the  SDTP  development,  where  the  classification  of  a  com¬ 
ponent  had  a  radical  effect  on  the  SDTP  architecture.  Our  modeling  technique 
also  offers  benefits  to  the  system  architect,  who  can  initially  develop  a  simple, 
abstract  system  architecture  that  is  easy  to  reason  about  but  is  too  restrictive 
for  implementation  purposes.  We  saw  this  in  the  abstract  SDTP  architecture, 
which  requires  that  all  components  provide  multilevel  access  control.  The  gap 
between  it  and  the  three  more  concrete  system  architectures,  which  are  less 
restrictive  with  respect  to  security,  was  bridged  by  refinement  mappings  that 
were  shown  to  preserve  the  security  property  of  the  abstract  architecture. 

It  is  important  to  mention  that  our  approach  to  architecture  modeling  is 
application  independent.  In  this  paper,  we  concentrated  on  the  X/Open  DTP 
reference  architecture  to  maximize  the  commercial  relevance  of  our  work.  How¬ 
ever,  our  approach  is  not  tied  to  any  particular  application  and  should  apply 
equally  well  in  the  development  of  other  secure  architectures. 

Future  work  includes  the  development  of  standard  refinement  rules  for  im¬ 
plementing  secure  architectures  in  execution  environments  containing  existing 
or  emerging  security  standards.  It  also  includes  an  extension  of  Sadl  to  model 
behavior-related  security  properties  using  the  Rapide  architecture  prototyping 
language.  This  would  make  it  possible,  for  example,  to  reason  about  covert 
channels  in  terms  of  a  system  architecture. 
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Chapter  3 

Proving  Faithfulness 


In  an  earlier  paper  on  the  foundations  of  correct  architecture  refinement  [26], 
my  colleagues  and  I  gave  a  model-theoretic  characterization  of  faithfulness.  Al¬ 
though  I  cannot  claim  that  this  characterization  is  original,  I  have  been  un¬ 
able  to  find  it  stated,  much  less  justified,  in  standard  references  on  model  the¬ 
ory  [6,  8,  15,  24,  44].^  This  paper  will  provide  the  justification.^ 

I  will  assume  that  the  reader  is  familiar  with  basic  logical  concepts,  such  as 
satisfaction,  model,  validity,  and  consistency.  Note  in  particular  that  a  sentence 
is  a  formula  containing  no  free  occurrences  of  variables,  and  that  a  theory  is 
a  set  of  sentences  that  is  closed  under  consequence.  The  logical  notation  used 
below  is  generally  standard  or  self-explanatory.  For  example, 

at=  V?[vo/ao,vi/ai,...  ,v„_i/an_i], 

which  will  usually  be  shortened  to 

211=  (p[ao,ai,...  ,a„_i] 

when  the  identities  of  the  free  variables  of  are  unimportant  (or  made  clear 
by  the  context),  means  that  the  assignment  of  values  ao,ai,...  ,an-i  in  the 
domain  of  the  structure  21  to  the  free  variables  vq,  Vi, . . .  ,  v„_i  of  the  formula 
if  satisfies  ip  in  21,  while 

2tl=</)(vo/to,Vi/ti,... 


or 


211=  V?(to,ti,...  ,tn-l) 

for  short,  means  the  formula  that  results  when  terms  to,ti, . . .  ,tn_i  are  simul¬ 
taneously  substituted  for  free  occurrences  of  the  variables  vo,vi,...  ,v„_i  in 

^One  reference  [44,  p.  96,  Problem  9c]  does  give  a  special  case  as  an  exercise. 

^We  originally  intended  to  include  this  argument  in  an  appendix  to  the  earlier  paper,  but 
decided  that  most  readers  of  the  journal  in  which  the  paper  appeared  would  not  find  it  helpful. 
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the  formula  c/?  (renaming  bound  variables  as  necessary  to  avoid  capture  of  the 
free  variables  of  ,tn-i)  is  true  in  the  structure  21.  The  prefix  “if-” 

will  frequently  be  used  to  emphasize  the  elementary  language  if  under  con¬ 
sideration.^  For  example,  saying,  that  (p  is  an  if -formula  means  that  all  the 
parameters  of  ^  are  among  the  parameters  of  if.  I  also  assume  that  the  reader 
is  familar  with  the  fundamentals  of  logical  metatheory,  including  the  Complete¬ 
ness  and  Compactness  Theorems  for  first-order  logic  and  the  Craig  Interpolation 
Theorem.  All  this  logical  background  can  be  found  in  any  good  logic  textbook, 
such  as  the  standard  model  theory  references  cited  above. 

For  our  purposes,"^  it  is  convenient  to  consider  an  interpretation  of  elementary 
language  if  in  elementary  theory  &  to  be  a  mapping  ^  from  if -formulas  to 
if '-formulas  that  (1)  “respects  logic”,  in  the  sense  that,  for  all  if -formulas  (p 
and  'ijj,  and  every  variable  v, 


A  'Ip) 
V  -0) 
y{ip  0) 
y  (Vv  (f) 
c/(3v  p) 


y{(p)  AJi'ip), 

y{(p)  V  c/(0), 

y  {(p)  y{'ip), 

Vv[a;jy(v)  J^(<p)],and 
3v[cjj?(v)  A  y{(p)]> 


where  ujy{v)  is  an  if '-formula  whose  only  free  variable  is  v,  and  (2)  satisfies 
the  following  conditions: 


&'  N  3vu;jir(v), 


and,  for  every  individual  parameter  a  of  if , 

0'  1=  3xi  Vxo  [  c/(xo  =  a)  xo  =  xi  ]. 

An  interpretation  of  if  in  if '-theory  &  is  an  mterpretatio'n  of  if-theory  0 
m  0'  iff,  for  every  if-sentence  p, 

e^if  ^  0'Nj^(v?). 

An  interpretation  of  0  in  &  is  faithful  iff,  for  every  if-sentence  (p, 

&  N  y{p)  =>  0  (^. 

As  a  first  step  toward  proving  the  main  result,  consider  the  notion  of  an 
elementary  embedding  of  one  structure  in  another.  For  any  relational  language 
if,  an  elementary  embedding  of  if-structure  21  in  if-structure  ©  is  a  function 
/  from  the  domain  of  21  to  the  domain  of  ©  such  that,  for  any  if-formula  p 

^ Since  only  pure  (i.e.,  non-logical  constant-free),  function  parameter-free,  elementary  lan¬ 
guages  will  be  considered  below,  languages  can  be  identified  with  the  set  of  their  predicate 
and  individual  parameters. 

Different  authors  define  interpretation  somewhat  differently.  Any  of  the  standard  textbook 
definitions  would  be  adequate  for  our  purposes. 
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and  any  assignment  of  values  ao,ai,...  ,nn-i  in  the  domain  of  21  to  the  free 
variables  of 

a  1=  i/)[oo,ai,...  ,o„_i]  iff  !B  (^[/(ao),/(ai),...  ,/(a„_i)] 

If  121  can  be  elementarily  embedded  in  IB,  then  21  and  03  “agree”  on  the  extension 
of  all  formulas.  In  that  case,  they  certainly  agree  on  the  truth  value  of  all 
sentences,  i.e.,  they  are  elementarily  equivalent. 

The  description,  or  elementary  diagram,  Ds(2l),  of  an  J5f-structure  21  with 
domain  A  is  obtained  as  follows:  expand  so  that  it  contains  a  name  a  for 
every  member  a  of  A;^  expand  21  to  a  structure  (2l,a)aGA  ^ov  the  language 
^  U  A,  where  A  =  {a:  a  £  A},  by  assigning  each  name  a  to  the  corresponding 
element  a;  let  Ds(21)  be  the  set  of  U  ^-sentences  true  in  (2l,a)a^^.  For  any 
if-structure  21,  any  ^-formula  (/?,  and  any  assignment  of  values  ao,  ai, . . .  ,  On-i 
in  A  to  the  free  variables  of  (p, 


21  ^p[ao,ai,,,,  ,an-i]  iff  (21,a)a€>i  ^=  v^(ao,ai,...  ,an~i) 

So  the  connection  between  elementary  embeddings  and  descriptions  is  straight¬ 
forward:  21  can  be  elementarily  embedded  in  IB  iff  23  can  be  expanded  to  an 
U  4-structure  that  models  Ds(2l). 

The  bulk  of  the  proof  will  consist  in  establishing  two  lemmas.  The  first 
lemma  establishes  a  relationship  between  descriptions  of  structures  and  faithful 
interpretations. 

Lemma  1 :  For  any  faithful  interpretation  of  consistent  j5f-theory  G  in  JSf 
theory  G'  and  any  model  21  of  0  wdth  domain  A,  the  set  of  sentences 
J^[Ds(2l)]  U  0'  is  consistent,  where  is  extended  from  to  U  4  by 
“mapping  each  new  name  a  to  itself”,®  i.e.,  for  every  atomic  ^-formula  (p 
and  every  substitution  of  names  aoiSi?  •  •  •  iSn-i  4  ^be  free  variables 
Vo,  vi , . . .  ,  v„>-i  of  let  y  map  atomic  ^  U  4-formula 


V?(vo/ao,vi/ai,...  ,v„_i/an_i) 

^Choose  fresh  names,  so  that  no  a  is  in  any  other  language  under  consideration. 
^Note  that  </?(vo/ao,  vi/ai , . . .  ,v„_i/an_i)  is  logically  equivalent  to 


3vo  3vi  . . .  3v 


A  Vi 

i<n 


ai  Av?  , 


(3.1) 


that  formula  (3.1)  is  mapped  to 


3vo  3vi  . . .  3v 


A  A  Vi -Si 


(3.2) 


[i<n  i<n  J 

by  y  if  every  equation  is  mapped  to  itself,  and  that  formula  (3.2)  is  logically  equivalent 

to 


i<n 
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to  U  4‘formula 


/\  wjf(ai)  A  (^(V?))(vo/ao,vi/oi, . . .  ,v„_i/fl„_i). 

i<n 


I  will  first  present  a  proof  of  this  lemma  for  the  special  case  of  conservative 
extensions  —  recall  that  if'-theory  0'  is  a  conservative  extension  of  ^-theory 
0  iff  the  identity  mapping  on  if -sentences  is  a  faithful  interpretation  of  0  in  0' 
—  in  order  to  highlight  the  essential  ideas.  Then  I  will  explain  how  the  proof  is 
modified  to  handle  other  interpretations. 

Suppose,  for  the  purpose  of  deriving  a  contradiction,  that  Ds(2l)  U  0'  is 
inconsistent.  Intuitively,  there  must  be  an  if -sentence  ip  such  that  Ds(2l)  implies 
that  (p  is  false  and  0'  implies  that  (p  is  true.  After  all,  Ds(2t)  says  nothing 
in  particular  about  the  additional  symbols  of  if ^  that  are  not  in  if ,  and  0 
says  nothing  in  particular  about  the  names  a  that  were  added  to  if  to  obtain 
if  U  A;  the  disagreement  between  the  two  theories  that  is  responsible  for  the 
inconsistency  should  be  expressible  in  the  common  part  of  their  languages.  This 
intuition  can  be  shown  to  be  correct  by  employing  the  metatheory  of  first-order 
logic.  According  to  the  Compactness  Theorem,  there  is  a  finite  subset  A  of 
Ds(2t)  and  a  finite  subset  Tof  0'  such  that  AUFis  inconsistent.  Equivalently, 

By  the  Completeness  Theorem, 


Therefore,  by  the  Craig  Interpolation  Theorem,  there  is  an  if -sentence  ip  such 
that 


\-l\r’^ip  and  I- A ^ 

Equivalently,  by  the  Soundness  Theorem, 

ri=  and  A  1= 

and  so 

ip  £  O’  and  6  Ds(2t) 

Since  if-sentence  ip  is  in  &  and  the  extension  is  conservative,  ip  is  in  0.  Since 
21  is  a  model  of  0,  ip  is  true  in  21  and  so  is  among  the  sentences  in  Ds(2t).  But 
this  is  impossible,  as  ip  was  chosen  so  that  -Mp  is  in  Ds(2l)  and  the  description  of 
a  structure  is  consistent  by  definition.  Because  the  supposition  that  Ds(2l)  U0' 
is  inconsistent  led  to  a  contradiction,  it  follows  that  Ds(2l)  U  O’  is  consistent. 

The  proof  for  interpretations  other  than  the  identity  is  much  the  same.  If 
we  had  used  the  more  restrictive  notion  of  interpretation  where  predicate  pa¬ 
rameters  are  mapped  to  predicate  parameters  and  individual  parameters  to  in¬ 
dividual  parameters  [44],  essentially  the  same  argument  used  above  would  work. 
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But  this  argument  breaks  down  when  our  more  liberal  definition  is  employed, 
because  interpretations  of  theories  need  not  be  theories,  and  so  a  consequence 
of  t/[Ds(2t)]  in  which  no  a  occurs  may  not  be  the  image  of  an  -formula  under 
^ ?  However,  it  is  easy  to  see  that  if  we  replace  the  target  language  with 
and  also  replace  ./[Ds(Ql)]  by  the  result  of  adding  both,  for  every  n-ary 
predicate  P  of  -£f ,  the  axiom 

Vvo  Vvi  ...Vvn_i  [  P(vo,Vi,...  ,Vn_i)  -H-  ^  (P(vo,  Vj ,  .  .  .  ,Vn_j))] 

and,  for  every  individual  parameter  c  of  -Sf,  the  axiom 

Vvo  [  Vo  =  c  -(->  J^(vo  -  c)  ] 

to  a  version  of  Ds(2l)  in  which  quantifiers  are  bounded  by  cj/,  the  consistency 
of  the  union  with  0'  is  unaffected.  Clearly,  the  two  “say  the  same  thing  about 
the  world”,  in  somewhat  different  languages.  So,  at  least  for  the  purpose  of  this 
argument,  an  interpretation  of  0  in  0^  can  be  viewed  as  an  interpretation  in 
the  more  restrictive  sense  of  0  in  a  definitional  extension  of  0^ 

The  second  lemma  says  that  interpretation  mappings  “preserve  meaning” . 

Lemma  2:  For  every  interpretation  of  JSf-theory  0  in  ^'-theory  0\  ev¬ 
ery  model  21'  of  0',  every  if  formula  (/?,  and  every  assignment  of  values 
oo,  Oi, . . .  ,  a„_i  in  the  domain  of  21'  to  the  variables  of 

y^(a')  1=  V?[ao,ai,...  ,a„_i]  iff  2t' t=  [ao,ai, . . .  ,a„_i] 

where  ^  is  the  natural  mapping  from  if '-structures  to  if-structures  de¬ 
termined  by  y:  the  domain  of  c/  ^{21')  is  the  same  as  the  domain  of  21',  the 
denotation  of  n-ary  predicate  P  of  if  in  c/^(2l')  is 

{{ao,ai,...  ,an-i>  :  2('  \=  Ji^(P(vo,  Vi , . . .  ,v„_i))  [gcGi,-..  ,an-i]} 

and  the  denotation  of  the  individual  parameter  c  of  if  in  J^^(2l')  is  the  a 
such  that  21'  N  c/(v  s  c)  [a]. 

Thanks  to  the  absence  of  function  symbols,  this  lemma  can  be  proved  by  a 
straightforward  induction  on  formulas.®  For  atomic  formulas,  the  result  is  an 
immediate  consequence  of  the  definition  of  If  v?  is,  say,  a  conjunction  'ipAx, 

^For  example,  if  0  is  the  set  of  consequences  of  the  {P}-formula  Vv  P(v)  and  ^  maps 
P(v)  to  Q(v)  A  R(v),  then  Vv  [  ay(v)  ->  Q(v)]  is  a  consequence  of  J^[6>)  but  is  not  the 
image  of  any  {P}-sentence  under 

® Inclusion  of  function  symbols  in  the  language  would  merely  require  that  the  base  case  of 
our  induction,  the  atomic  formulas,  be  established  by  induction  on  the  number  of  function 
symbols  that  occur  in  atoms. 
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then 

1=  i'lpAx)  [ao,ai,...  ,an-i] 

iff  y  ^(21')  \=  'ip  [ao,ai, . . .  ,an-i]  and  x  . .  ,a„_i] 

(By  the  definition  of  satisfaction) 

iff  21'  1=  [ao,ai,...  ,a„-i]  and  21'  ^  y{x)  ,Gn^i] 

(By  the  induction  hypothesis) 

iff  21'  1=  {J^i'tp)  A  y{x))  [ao,ai,...  ,a„^i] 

(By  the  definition  of  satisfaction) 

iff  21'  1=  J^iip  Ax)  [ao,ai,...  ,a„_i] 

(By  the  definition  of  interpretation) 

The  argument  for  the  other  connectives  and  quantifiers  is  similar. 

The  main  result  is  an  easy  consequence  of  the  lemmas. 

Theorem:  For  any  interpretation  ^  of  elementary  -£f -theory  6  in  elementary 
J^'-theory  0\  the  following  are  equivalent: 

(1)  y  is  faithful; 

(2)  for  every  model  2t  of  0  there  is  a  model  21'  of  &  such  that 
c/^(2l')  can  be  expanded  to  a  model  of  Ds(2l); 

(3)  for  every  model  21  of  0  there  is  a  model  21'  of  0'  such  that  21 
can  be  elementarily  embedded  in  ./^(2l'). 

Proof  that  (1)  implies  (2):  Let  21  be  a  model  of  0.  According  to  Lemma  1, 
c/[Ds(2l)]  U  0'  is  consistent.  Let  21'  be  the  reduct  of  some  model  25  of  this 
theory  to  J^'.  The  structure  J^^(25),  which  is  an  expansion  of  c/^(2l')  to 
U  is  a  model  of  Ds(2l),  by  Lemma  2. 

Proof  that  (2)  implies  (3):  This  follows  from  the  connection  between  elementary 
embeddings  and  descriptions  noted  above. 

Proof  that  (3)  implies  (1):  Let  be  an  if-sentence  such  that  ^{(p)  is  in  0'. 
Suppose  that  21  is  a  model  of  0.  By  hypothesis,  there  is  a  model  21'  of  0' 
such  that  21  can  be  elementarily  embedded  in  J^^(2l').  Since  21'  is  a  model 
of  0'  and  J^(v?)  is  in  0',  J^{(p)  is  true  in  21'.  But  then,  using  Lemma  2,  cp 
is  true  in  c/^(^'),  which  is  elementarily  equivalent  to  21.  Generalizing,  ip 
is  true  in  every  model  of  0,  and  hence  is  a  member  of  0. 

Intuitively,  the  theorem  can  be  thought  of  as  saying  that  an  interpretation 
of  first-order  theory  0  in  first-order  theory  0'  is  faithful  iff,  for  every  model 
21  of  0,  there  is  a  model  21'  of  0'  such  that,  when  the  “abstraction  map”  is 
applied  to  21',  the  structure  that  results  cannot  be  distinguished  from  21  using 
the  resources  of  first-order  logic.  This  suggests  that  analogous  results  can  be 
established  when  a  different  logic  is  used  to  formalize  the  architectures.  For 
example,  the  logic  L‘^,  often  called  higher-order  logic  or  simple  type  theory,  can 
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characterize  any  structure  up  to  isonaorphism.^  One  would  therefore  expect 
that  an  interpretation  J  of  an  theory  €>  in  an  theory  &  is  faithful  iff,  for 
every  model  2t  of  0,  there  is  a  model  21'  of  &  such  that  c/^(2l')  is  isomorphic  to 
21.  It  is  easy  to  prove  that  this  expectation  is  correct.  Formulating  and  proving 
analogues  of  the  theorem  for  other  logics  of  interest  is  left  as  an  exercise. 


allows  quantification  over  relations  among  individuals  (or,  equivalently,  functions  from 
individuals  to  individuals),  relations  among  relations  among  individuals  (or  functions  from 
functions  on  individuals  to  functions  on  individuals),  and  so  on. 
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Chapter  4 

Correctness  of 
Architectural  Refinements: 
a  simplified  approach 


4.1  Two  Approachs  to  Establishing  Correctness 

In  a  previous  paper  [26],  my  colleagues  and  I  presented  an  approach  to  prov¬ 
ing  correctness  of  architectural  refinement  patterns.  A  correspondence  between 
architectural  specifications,  such  as  the  high-level  compiler  specification  in  Fig¬ 
ure  4.1,  and  theories  in  first-order  logic  was  defined  in  terms  of  a  mapping  from 
specification  elements  to  axioms  for  the  theories.^  For  example,  the  presence 
of  the  dataflow  connector  that  carries  objects  of  type  AST  (i.e.,  abstract  syn¬ 
tax  trees)  from  the  parser  component  to  the  analyzer/optimizer  component  in 
Figure  4.1  corresponds  to  the  axioms 

Channel(astJntermediate) 

Vxo  [AST(xo)  Can>Carry(astJntermediate,xo)  ] 


The  theory  that  corresponds  to  a  specification  is  simply  the  set  of  all  conse¬ 
quences  of  the  axioms  obtained  from  the  elements  of  the  specification,  together 
with  general  axioms  that  constrain  the  meanings  of  the  component,  port,  and 
connector  predicates  that  appear  in  the  specification. 

This  theory  is  rather  weak,  in  the  sense  that  it  does  not  determine  the  truth 
value  of  many  sentences  in  the  language.  For  example,  it  does  not  contain  any 
explicit  “extremal  axioms”  to  preclude  the  existence  of  additional  objects  not 

^  Strictly  speaking,  the  content  of  the  informal  dataflow  diagram  was  formalized  in  a  textual 
specification  language.  For  the  purposes  of  this  paper,  let  us  eliminate  the  middleman  and  pre¬ 
tend  that  diagraunmatic  representations  are  sufficiently  precise  to  serve  as  formal  architectural 
specifications. 


31 


Figure  4.1:  Dataflow  Architecture  for  a  Compiler 


mentioned  in  the  specification.  Neither  the  sentence 

“1 3xo3xi 3x2  [  Out>Port(xi ,  parser) 

A  ln_Port(x2,  lexicaLanalyzer)  A  Connects(xo,  Xi,X2)  ] 

which  says  that  there  is  no  dataflow  channel  from  the  parser  to  the  lexical 
analyzer,  nor  its  negation,  is  a  consequence  of  the  theory  that  corresponds  to 
the  architecture  in  Figure  4.1.  Of  course,  that  no  such  dataflow  channel  is 
shown  means  that  the  specifier  intended  that  no  such  channel  be  implemented 
(or,  more  accurately,  that  no  such  channel  should  be  observable  at  this  level 
of  abstraction).  Some  of  these  “truth  value  gaps”  can  be  eliminated  by  adding 
axioms,  but  perhaps  not  all;  the  theory  of  an  inductive  datatype,  such  as  AST, 
may  well  be  essentially  incomplete.  Nonetheless,  our  theories  are  treated  as 
if  they  were  complete,  in  the  sense  that  our  criterion  for  correct  refinement  is 
that  the  higher-level  theory  must  be  faithfully  interpretable  in  the  lower-level 
theory.^  In  other  words,  the  lower-level  theory  must  not  add  any  detail  that 
could  have  been  expressed  at  the  higher  level,  such  as  the  existence  of  additional 
unmentioned  objects  in  the  higher-level  ontology. 

But  there  is  an  alternative,  perhaps  more  natural,  logical  interpretation  of 
the  dataflow  diagram  in  Figure  4.1.  Any  application  of  mathematics  requires 
construction  of  a  mathematical  model  of  some  phenomena  of  interest.  This 
mathematical  model  must  share  relevant  structure  with  the  phenomena,  so  that 

^Recall  that  an  interpretation  the  language  of  theory  0  in  the  theory  0'  is  an  inter¬ 
pretation  of  0  in  0'  iff  for  every  sentence  <f  in  the  language  of  0, 

^  0  €  0' 

If,  in  addition,  for  every  sentence  in  the  language  of  6, 

G  0'  V’  €  © 


then  J  is  said  to  be  faithful. 


conclusions  derived  from  reasoning  about  the  structure  of  the  model  are  true 
of  the  structure  of  the  phenomena  being  modeled  as  well.  Examples  axe  ubiq¬ 
uitous  in  computing.  For  example,  one  might  attempt  to  derive  truths  about 
the  behavior  of  a  particular  parsing  program  running  on  a  particular  machine 
by  reasoning  about  a  finite  state  automaton  that  mathematically  models  it.  It 
seems  very  natural  to  suppose  that  this  is  exactly  the  function  a  system  speci¬ 
fication,  whether  behavioral  or  architectural,  is  supposed  to  perform.  In  short, 
from  this  alternative  perspective,  architectural  specifications  are  intended  to  be 
mathematical  models  of  the  systems  they  specify. 

Just  as  a  finite  state  automaton,  which  is  formally  defined  as  some  sort  of 
mathematical  structure,  can  be  depicted  as  a  collection  of  boxes  and  arrows, 
a  system  architecture  diagram  can  be  construed  as  a  depiction  of  a  particu¬ 
lar  mathematical  structure.  Consider  once  again  the  dataflow  diagram  of  Fig¬ 
ure  4.1.  The  similarity  type  of  the  structure  that  this  diagram  depicts  is  deter¬ 
mined  by  its  architectural  style.  Since  this  is  a  dataflow  diagram,  the  structure 
must  provide  the  extensions  for  the  various  predicate  parameters  of  the  dataflow 
language  —  Channel,  AST,  Can.Carry,  and  so  on  —  and  must  also  identify  the 
particular  individuals  denoted  by  the  individual  parameters  of  the  specification, 
such  as  parser.  (Note  that  this  structure  is  not  finite.  Most  often,  the  number  of 
components  and  connectors  in  specifications  will  be  finite,^  but  the  datatypes 
are  often  infinite.) 

In  the  “model-based”  treatment  of  specifications,  the  logical  theory  that 
corresponds  to  the  specification  is  simply  the  theory  of  the  structure  that  the 
specification  depicts.  This  theory  is,  of  course,  complete,  which  is  important  be¬ 
cause  every  standard  interpretation"^  of  a  complete  theory  in  a  consistent  theory 
is  faithful  The  proof  of  this  fact  is  easy:  for  any  standard  interpretation  of 
complete  theory  9  in  consistent  theory  0'  and  any  sentence  (p  of  the  language 


- i -  ^ 

of©, 

(fie  => 

G  0 

(0  is  complete) 

G  0^ 

(c/ interprets  0  in  &) 

G  0^ 

(St’d  interp’ns  preserve  logic) 

^{(p)  ^  0^ 

(0'  is  consistent) 

and  so,  universally  generalizing  the  contrapositive,  J^is  faithful. 

In  the  “property-oriented”  treatment  of  our  previous  paper,  proving  that 
the  standard  interpretation  associated  with  a  candidate  refinement  is  a  theory 
interpretation  was  easy.  A  standard  interpretation  maps  derivations  to  deriva¬ 
tions.^  Therefore,  if  finite  axiomatizations  of  0  and  0'  are  available,  then  it 
can  be  shown  that  interprets  0  in  0'  by  deriving  the  image  of  each  axiom  of 

^However,  it  might  sometimes  be  convenient  to  model  a  conceptually  unbounded  number 
of  components  or  connectors  by  an  infinite  number  of  components  or  connectors,  just  as  a 
Turing  machine’s  infinite  tape  is  used  to  model  conceptually  unbounded  memory. 

^See  the  Section  4.2  for  the  definition  of  standard  interpretation. 

5  Actually,  the  derivations  that  result  can  contain  small  “gaps”  due  to  the  introduction  of 
bounds  on  quantifiers,  but  filling  these  in  is  trivial. 
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&  under  J^from  the  axioms  of  0\  But  proving  faithfulness  is  harder.  A  sub¬ 
stantial  model-theoretic  result  served  as  the  basis  of  the  method  we  proposed. 
So  the  fact  that  faithfulness  is  automatic  on  the  new  approach  makes  it  look 
quite  promising.  Unfortunately,  there  is  no  simple,  mechanical  way  to  obtain 
axioms  for  the  theory  of  a  structure  from  a  representation  of  that  structure. 
Indeed,  the  theory  of  the  structure  corresponding  to  some  specifications  may 
very  well  have  no  recursive,  much  less  finite,  axiomatization.  Some  other  way 
is  required  for  recognizing  when  a  basis  mapping  from  the  parameters  of  the 
language  of  one  structure  to  the  language  of  another  structure  determines  a 
standard  interpretation  of  the  theory  of  the  former  struture  in  the  theory  of  the 
latter  structure. 


4,2  Brief  Introduction  to  Interpretations 


Two  different  sorts  of  definition  of  the  term  interpretation  appear  in  the  litera¬ 
ture.  Logic  textbooks  [8,  15,  44]  provide  rather  concrete  definitions,  explaining 
in  some  detail  how  mappings  from  the  symbols  of  one  theory  to  the  expres¬ 
sions  of  another  can  be  extended  to  mappings  from  sentences  to  sentences  and 
exploring  the  properties  of  those  mappings.  For  more  advanced  purposes  [2, 
pp.  470-471],  more  abstract  definitions  are  often  preferred.  The  main  advan¬ 
tage  of  a  more  abstract  approach  is  flexibility.  Many  more  mappings  can  count 
as  interpretations  if  an  abstract  approach  is  adopted.  But  flexibility  ha.s  a  cor¬ 
responding  cost.  Most  important,  if  an  interpretation  is  not  defined  inductively 
on  formulas,  then  inductive  proofs  of  properties  of  the  interpretation  become 
much  more  complicated. 

For  our  applications,  considerable  flexibility  is  occasionally  required  [41]. 
Therefore,  our  definition  is  maximally  abstract:  an  interpretation  J  of  the 
theory  &  in  the  theory  &  is  a  (total)  mapping  from  the  sentences  of  the  language 
^of  0  to  the  sentences  of  the  language  -Sf'  of  &  such  that,  for  every  ^-sentence 


G  0  ‘^(^)  €  & 


While  it  is  desirable  that  interpretations  preserve  meaning,  in  some  sense,  there 
is  no  formal  requirement  that  they  do  so.  However,  an  informal  argument  that, 
for  every  J5f-sentence  is  semantically  stronger  than  may  be  offered  as 

evidence  that  the  interpretation  is  “natural” .  An  interpretation  c/  of  0  in  &  is 
faithful  when,  for  every  J5f-sentence  (/?, 

€  0^  =>  V?  €  0 

In  many  cases,  interpretations  will  be  defined  in  a  way  that  allows  straight¬ 
forward  inductive  proofs  to  be  performed.  Interpretations  of  theory  0  in  theory 
0'  will  often  be  defined  by  giving  a  basis  mapping  J  from  the  parameters 
{□,  P, . . .  ,  a, . , .  of  J^,  the  language  of  0,  to  formulas  of  the  language  of 
0',  that  satisfies  the  following  three  conditions: 

is  a  special  parameter  of  the  language  JSif ,  the  universe  parameter,  that  does  not  actually 
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(i)  xo  is  the  only  free  variable  of  J^{D)  —  which  will  generally  be  called  ujj^ 
rather  than  ^(D)  —  and 

0'  3xo  cjy 

(iz)  for  every  n-ary  predicate  P  of  -Sf ,  the  free  variables  of  )  are  xq,  xi , . . .  ,  x^—i , 
and 

(Hi)  for  every  name  a  of  xq  is  the  only  free  variable  of  -^(a)  and 

0'  N  Bxi  Vxo  [  c/(a)  <H'  Xo  =  xi  ]. 

These  conditions  can  be  restated  as 
(i)  the  formula  defines  a  non-empty  set, 

(m)  for  every  n-ary  predicate  P  of  the  formula  o^(P)  defines  an  n-ary 
relation  on  the  set  defined  by  cjjsr,  and 

(Hi)  for  every  name  a  of  the  formula  J^(a)  defines  a  member  of  the  set 
defined  by  Ujf, 

which  emphasizes  the  fact  that  they  are  syntactic  analogues  of  the  three  defining 
conditions  for  an  J^-structure  21, 

(i')  the  universe  |2l|  of  21  is  non-empty, 

(ii^)  for  every  n-ary  predicate  P  of  J5f,  P^  is  an  n-ary  relation  on  |2t|,  and 

(Hi')  for  every  name  a  of  a^  is  a  member  of  12t|. 

The  mapping  can  be  extended  to  a  map  from  -Sf-formulas  to  -formulas 
in  a  straightforward  fashion.  If  (f  is  an  atomic  -$f- formula  say,  P(a,  x),  where 
P  is  a  binary  predicate,  a  is  a  name,  and  x  is  a  variable  then  *^(^)  is 

3y  [(^(a))(xo/y)  A  (J^(P))(xo/y,xi/x)] 

where  y  is  a  fresh  variable.  If  «^{a)  is  an  equation  xo  ^  c/(P(a,x))  will  be 

simplified  to 

(c/(P))(xo/a',xi/x) 

(Note  that  J^(P(xo,xi, . . .  ,x„^i))  is  simply  ^(P)  and  that  J^(xo  =  a)  is  simply 
J^(a).)  Now  that  c/has  been  defined  on  all  atomic  formulas,  it  can  be  extended 
to  all  formulas  as  follows: 

1.  for  any  j5f-formula  (p, 

J(’-yip)  =  -n  J(^p) 

occur  in  ^-formulas.  This  allows  us  to  treat  a  structure  as  a  mapping  from  the  parameters  of 
^  to  appropriate  denotations  —  so  12t|  is  simply  —  and  similarly  allows  us  to  treat  the 
basis  of  an  interpretation  as  a  mapping  from  the  parameters  of  if  to  appropriate  if  -formulas. 
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2.  for  any  J^-formulas  and  ip, 


c/(c/3  A'lp)  =  A  ^(ip) 

3.  for  any  J5f- formulas  (p  and  ip, 

v  tp)  =  V  j^{'ip) 

4.  for  any  .Sf-formulas  ip  and  ip, 

J{ip  ^xp)  =  y{p)  — >  ^{'ip) 

5.  there  is  an  if' -formula  uy,  called  the  universe  of  the  interpretation,  such 
that  for  any  variable  x  and  any  if-formula 

c/(Vx  (y?)  =  Vx  [  u;y{xo  fx)  y{p)  ] 


and 


y{3xp)  =  3x  [ujy{xo/x)  A  J^{p)] 

An  interpretation  that  is  defined  on  formulas  as  well  as  sentences  and  satisfies 
these  five  conditions  will  be  said  to  preserve  logic.  Preservation  of  logic  is 
required  if  straightforward  inductive  proofs  of  properties  of  an  interpretation 
are  to  be  performed.  Mappings  defined  by  starting  with  a  basis  and  extending 
it  as  described  above  will  be  called  standard  interpretations  of  -Sf  in  -$f'. 

A  standard  interpretation  y  of  language  -$f  in  language  is  an  interpret 
tation  of  if  in  if'-theory  0'  iff 


0'  N  3xo  ujy 

and,  for  every  individual  parameter  a  of  if, 

0'  1=  3xi  Vxo  [  y{xo  =  a)  -H*  xo  =  xi  ] 

Of  course,  a  standard  interpretation  o^of  if  in  if'-theory  0'  is  an  interpretation 
of  if-theory  0  in  0'  if,  for  every  sentence  ip  of  the  language  of  0, 

ip  e  0  yi^)  ^ 

and  it  is  faithful  if,  in  addition,  for  every  if-sentence  p, 

jp[ip)  e&  p^o 

The  main  result  about  standard  theory  interpretations  that  is  needed  for 
this  paper  is  that  they  always  preserve  meaning,  in  a  sense  made  precise  by  the 
following  theorem. 
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Theorem  For  any  standard  interpretation  J  of  language  ^  in  -theory  & , 
any  model  21'  of  & ,  any  formula  (p  of  and  any  assignment  x  of  values  in 
to  the  free  variables  of  p, 

21'  t=  y{ip)  [x]  J^®{21')  if  [x] 

Proof.  It  is  immediate  from  the  definition  of  that  the  equivalence  holds  for 
every  atomic  formula  p  of  Jf.  That  it  also  holds  for  non-atomic  J^-formulas 
follows  easily  by  induction.  For  example,  if  v?  is  -0  A  Xj  then 

^  (0  A  x)  [x]  1=  0  [x]  and  1=  x  M 

(Definition  of  satisfaction) 

21'  f=  J^(0)  [x]  and  21'  1=  J^(x)  [x] 

(Induction  hypothesis) 

21'  N  (J^(0)  A  y{x))  M 

(Definition  of  satisfaction) 

<=>  21'  ^  J^(0  A  x)  [a:] 

(Definition  of  interpretation) 

4.3  A  Model-Theoretic  Criterion  for  Theory  In¬ 
terpretation 

Any  standard  interpretation  of  the  language  in  an  j5f'-theory  0'  induces  a 
“dual”  mapping  from  if '-structures  to  if-structures:  roughly  speaking,  the 
denotation  of  a  predicate  of  if  is  determined  by  the  extension  of  the  if'-formula 
that  interprets  the  predicate  in  the  if'-structure,  and  similarly  for  individual 
parameters.  More  formally,  given  a  model  21'  =  (|2l'|,P*“  , . . .  ,a®  , . . . )  of  0', 
the  if-structure  y®(2l')  =  (|J^®(2l')|,P'''®(®‘'\ . . .  . . .)  is  determined 

as  follows: 

1.  let 


|y®(2l')|  =  {xo€  |a'|  :2l'l=tcy[xo]} 

where  uo?,  the  if'-formula  that  bounds  interpreted  quantifiers,  defines  the 
subset  of  |2l'|  used  to  interpret  |2t|, 

2.  for  every  n-ary  predicate  parameter  P  of  if,  let 

p./®(2i')  _  ,x„_i)  €  iy®(2l')|"  : 

21'  t=  J^(P(xo,Xi,...  ,x„_i))  [xo.xi,...  ,x„_i]} 


and, 
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3.  for  every  individual  parameter  a  of  let  *  be  the  xo  in  |2l’|  such 

that 


i2l'  1=  y(xo  =  a)  [xo] 

It  is  easy  to  show  that  if  y  is  a  standard  interpretation  of  the  language  of 
the  structure  121  in  the  theory  of  the  structure  121'  and  is  isomorphic  to  121, 

then  o/ interprets  the  theory  of  21  in  the  theory  of  21' J  Let  /  be  an  isomorphism 
from  21  to  J«^®(21').  Then,  for  every  ^-formula  and  every  assignment  x  of 
values  in  \%  to  the  free  variables  of  v?, 

21I=(^[2:]  ^  ip[f  o  x] 

(Definition  of  isomorphism) 

21'  ^  [/  o  x] 

(Theorem  of  Section  4.2) 


A  fortiori,  ./is  a  theory  interpretation. 

This  theorem  suggests  that  be  viewed  as  an  abstraction  mapping  that 
corresponds  to  standard  interpretation  c/.  It  says  that  structure  21'  is  a  correct 
refinement  of  structure  21,  relative  to  an  interpretation  of  the  language  of  21 
in  the  language  of  21',  if  y^{Qi')  —  the  result  of  abstracting  away  the  features 
of  21'  not  expressible  in  the  language  of  21  —  is  21  (up  to  isomorphism). 

'^Recall  that  the  theorem  that  provided  the  basis  for  establishing  faithfulness  of  standard 
first-order  theory  interpretations  on  our  original  approach  was 

Interpretation  of  the  theory  0  in  the  theory  0'  is  faithful  iff,  for  every  model 
21  of  0,  there  is  a  model  21'  of  0'  such  that  JJ^^(2l')  can  be  expanded  to  a  model 
of  the  description  of  21. 
or,  equivalently, 

Interpretation  y  of  the  theory  0  in  the  theory  0'  is  faithful  iff,  for  every  model 
21  of  0,  there  is  a  model  21'  of  0'  and  a  function  from  |2l|  into  |2l'|  such  that 

(2t,a)a6l2ii  =  (‘^^(2l'),/(a))a€|ai 
where  ‘=’  denotes  elementary  equivalence. 

It  follows  that  requiring  ^^(21')  to  be  isomorphic  to  21  is  not  necessary  for  faithfulness.  But 
this  is  simply  an  artifact  of  the  limited  expressive  power  of  first-order  logic;  in  tJ-order  logic, 
also  known  as  higher-order  logic  and  the  theory  of  types,  isomorphism  is  both  necessary  and 
sufficient  for  faithfulness.  In  the  approach  advocated  in  this  paper,  formal  logical  derivations 
have  been  eliminated  —  derivations  are  no  longer  used  in  proving  correctness,  and  the  ques¬ 
tion  of  whether  a  formula  can  be  derived  from  the  theory  corresponding  to  a  specification  has 
been  replaced  by  the  question  of  whether  the  structure  corresponding  to  that  specification  is 
a  model  of  that  formula  —  and  so  there  is  no  compelling  meta-theoretical  reason  to  restrict 
ourselves  to  first-order  logic.  It  would  even  be  tempting  to  replace  the  notion  of  interpreting 
one  theory  in  another  by  that  of  interpreting  one  structure  in  another  ([15],  pp.  212),  except 
that  we  exploit  intuitions  about  what  a  specification  says  to  motivate  the  necessity  of  faithful 
interpretation.  By  focusing  on  isomorphism  rather  than  finite  isomorphism^  the  usual  alge¬ 
braic  characterization  of  elementary  equivalence  [7],  the  dependence  of  this  approach  on  a 
particular  choice  of  logic  is  largely  eliminated.  However,  the  account  below  will  be  restricted 
to  first-order  theories  of  structures,  to  enable  more  direct  comparison  of  the  new  approach 
and  the  original. 
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Figure  4.2:  Refinement  Pattern:  Dataflow  Channel  to  Variable 


4.4  An  Example 

To  enable  direct  comparison  with  the  correctness  proof  sketch  in  our  previous 
paper,  the  same  refinement  pattern,  replacement  of  a  single  dataflow  channel 
by  writing  and  reading  of  a  variable,  will  be  proven  correct.  This  pattern  is 
presented  graphically  in  Figure  4.2. 

A  refinement  pattern  consists  of  a  pair  of  schematic  diagrams,  diagrams  in 
which  some  terms  have  been  replaced  by  syntactic  variables.  The  syntactic 
variables  of  this  pattern  are  a,  b,  c,  v,  and  T.  A  pair  of  structures  (2),9H) 
matches  this  pattern  iff,  for  some  assignment  of  values  to  the  syntactic  variables, 
the  diagram  above  the  bold  arrow  depicts  S  and  the  diagram  below  the  arrow 
depicts  9Jl.  The  pattern  is  correct  iff,  for  every  pair  of  structures  (33,971)  that 
matches  the  pattern,  931  is  a  correct  refinement  of  ©.  So,  if  a  pair  of  structures 
matches  a  correct  refinement  pattern,  the  second  is  a  correct  refinement  of  the 
first. 

The  class  of  structures  depicted  by  the  schematic  diagram  above  the  arrow 
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can  be  more  formally  defined  as  follows: 


|J)|  =  {a,b,c,po,Pi}UT 
Procedure®  =  {a,  6} 

Channel®  =  {c} 

In-Port®  =  {(Pi,6)} 

Out-Port®  =  {(Po,a)} 
Can-Carry®  =  {(c,  t)  :t  eT} 
Might-Supply®  =  {{po,t)  :t£T} 
Can-Accept®  =  {{pi,t)  :teT] 
Connects®  =  {{c,po,Pi)} 

rpD  _  rp 


a.oport®  =  po 
bJport®  =  Pi 

where  a,  b,  c,  po,  and  pi  are  some  five  distinct  objects,  none  of  which  is  a  member 
of  the  set  T.®  Similarly,  the  class  of  structures  depicted  by  the  schematic  dia¬ 
gram  that  gives  the  implementation  of  the  dataflow  in  terms  of  shared  memory 
is  defined  as  follows: 


m\ 

=  {a,b,v, 

Procedure®' 

=  {a,  ft} 

Variable®' 

=  W 

Call®' 

^,{kr,b)) 

Can-Hold®' 

=  {{v,t): 

teT} 

Might-Put®' 

:tgr} 

Can-Get®' 

■4-i 

II 

:ter} 

®The  names  and  types  of  the  ports  are  not  explicitly  given  by  the  graphical  specification; 
the  names  are  generated  and  the  types  are  inferred,  according  to  the  principle  that  the  type 
of  a  port  is  the  type  of  the  channel  connected  to  it  unless  there  is  some  explict  indication  to 
the  contrary. 
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Writes®  =  {{ku,,v)} 

Reads®  =  {(fcr.t')} 

rjiSUl  _  fjy 

=  a 
h^  =  b 

Y^=V 

a_call^  =  ky, 
b_calP  =  kr 

where  o,  6,  v,  ky^,  and  kr  are  some  five  distinct  objects,  none  of  which  is  a 
member  of  the  set  T.  Here,  the  names  of  the  calls  have  been  generated  and  the 
signatures  of  the  calls  inferred  from  types  and  sorts  of  calls. 

Consider  the  basis  mapping  from  the  parameters  of  the  language  of  S)  to 
formulas  in  the  language  of  VJl  defined  as  follows: 

UJjfT  =  Xo  =  Xo 

J^(Proc€dure)  =  Procedure(xo) 

J(^{Ch^r\r\e\)  =  Variable(xo) 
jr(ln.Port)  =  Call(xo,xi)  A  3x2  Can-Get(xo,X2) 
c;f(Out-Port)  =  Call(xo,Xi)  A  3x2  Might..Put(xo,X2) 
Jf(CanXarry)  =  Can_Hold(xo,xi) 
jr(Might.Supply)  =  Might-Put(xo,xi) 

J^(Can-Accept)  =  Can_Get(xo,Xi) 

Jf^(Connects()  =  Writes(xi,xo)  A  Reads(x2,xo) 
jr(T)  =  T(xo) 

=  xo  =  a 
jr(b)  =  xo  -  b 
J^(c)  =  Xo  =  V 

Jf(a-oport)  =  xo  =  a-call 
J^(bJport)  =  xo  ^  b-call 

The  first  eight  clauses  in  the  definition  are  determined  by  the  general  style 
mapping  for  interpreting  datafiow  style  in  shared  memory  style.  The  last  six 
clauses  are  determined  by  the  identifier  mapping  associated  with  this  particular 
refinement  step.®  If  this  basis  mapping  is  extended  to  an  interpretation  of 
formulas  in  the  language  of  2)  in  the  standard  way,^®  an  interpretation  of  the 
language  of  D  in  the  theory  of  results. 

our  previous  paper  [26]  for  a  more  detailed  account  of  style  and  identifier  mappings. 
^®See  Section  4.2. 
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Now  the  value  of  the  abstraction  map  at  DJI  can  be  calculated,  using  its 
definition.^* 

\J^{DJl)\  =  {lo  €\DJl\:DJl\-  u>x[xo]] 

=  {xo  e  |OT|  :  971 1=  Xo  =  Xo  [lo]} 

=  \DJl\ 

Procedure'*^^*®’*  =  {xq  6  |9Jl|  :  9J?  N  Jf(Procedure)  [xq]} 

=  {xo  e  |9}?|  :  971 1=  Procedure(xo)  [xo]} 

=  {a, 6} 

Channel”*"**®'^  =  {xo  6  |97i|  :  97t  ^  Jt^(Channel)  [xq]} 

=  {xo  €  |97?|  ;  971 1=  Variable(xo)  [xq]} 

= 


In-Porf^**®^*  =  {{xo,xi)  e  |971|^  :  DJI  t=  X(ln.Port)  [xo,xi]} 

=  {{a:o,ii)  e  |97Ip  ; 

971  N  Call(xo,xi)  A  3x2  Can-Get(xo,X2)  [xo.xi]} 

—  {{^W)  u)} 

Out-Porf*"**™’  =  {(xo,xi)  €  |971|^  :  971  N  jr(Out.Port)  [xo,Xi]} 

=  {(xo,xi)€|971|^ 

971 1=  Call(xo,xi)  A  3x2  Might.Put(xo,X2)  [xo,xi]} 

=  {{kr,b)} 

Can.Carry^*^®*’  =  {(xo.xi)  €  |971|^  :  971 1=  jr(Can.Carry)  [xo,xi]} 

=  {(xo,xi)  e  |971p  :971l=  Can-Hold(xo, Xi)  [xo.xi]} 

=  {{c,t)  ;  t  €  T} 

Might^upply'^®^®'*  =  {(xo,xi}  e  |971p  :  971 1=  jr(Might-Supply)  [xo,ii]} 

=  {<Xo,Xi)  €  |971p  :  971  N  Might-Put(xo,xi)  [xo,xi]} 

=  {(k^,t)  iteT} 

CanJ^ccept'*^*'®'^  =  {(xo,xi)  e  |971p  ;  971  N  jr(Can_Accept)  [xo,xi]} 

=  {(xo,xi)  €  |971p  :  971 1=  Can.Get(xo,xi)  [xo,xi]} 

=  {(kr,t)  :teT} 

Every  parameter  of  the  language  of  D  is  treated  below,  for  the  sake  of  completeness,  but 
all  calculations  are  similar  and  there  is  no  need  to  read  them  all  unless  you  are  so  inclined. 
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Connects'^**®'^  =  {(a:o,a:i,a:2)  €  M  t=  jr(Connects)  [xo,2i,a;2]} 

=  {(xo,a;i,X2)  €  |5H|^  ; 

9Jl  \=  Writes(xi,xo)  A  Reads(x2,xo)  [xo,xi,X2]} 

—  {(c,  kyj^  ^r)} 

Tjr«(OT)  ^  ^3.^  g  |gjj|  .  3JJ  ^  X{T)  [xo]} 

=  {xo  €  |9ni  :  9Jt  ^  T(xo)  [xo]} 

=  r 

^  (,3.^  g  |gjj|)  9JJ  [xo] 

=  (7x0  e  |9ni)  jm  N  Xo  -  a  [xo] 

=  a 

^  (33.^  g  |9jl|)  2JJ  ,=  j^(b)  [a;^] 

=  (7x0  e  |9Ji|)  an  t=  Xo  =  b  [xo] 

=  b 

^  (,3.^  g  |gjj|)  gjt  1=  X'(C)  [xo] 

=  (7x0  6  \Tt\)  sot  t=  Xo  =  V  [xo] 

=  V 

a.oport‘^"®<®”^  =  (7x0  €  |S!JI|)  9Jt  1=  Jf(a.oport)  [xo] 

=  (7x0  €  |97ll)  9W  t=  Xo  =  a-call  [xo] 

—  k-m 

bJport-^®^®'^  =  (7x0  €  janj)  an  l=  jr(bJport)  [xo] 

=  (7x0  €  |an|)  an  t=  Xo  =  b.caii  [xo] 

=  kr 

Clearly,  if  h  from  |S|  to  |an|  is  defined  by 

h{a)  =  o 
hib)  =  b 

h{c)  =  V 
h{po)  =  fcui 
h{pi)  =  kr 

hit)  =  t  (for  every  t  €  T) 

then  h  is  an  isomorphism  from  D  to  Jt^(Tl),  and  so  J^'is  indeed  an  interpreta¬ 
tion  of  the  theory  of  D  in  the  theory  of  an. 
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Compare  this  proof  and  the  correctness  proof  sketch  in  our  previous  paper. 
In  the  latter,  ^ve  had  to  show  that,  for  any  model  of  the  dataflow  theory,  there 
was  a  model  of  the  shared  memory  theory  with  a  certain  desirable  property,  viz., 
that  the  image  of  the  shared  memory  model  under  the  abstraction  mapping  is 
indistinguishable  from  the  dataflow  model  using  the  resources  of  the  relevant 
logic:  see  Figure  4.3.  Thus,  a  mapping  from  dataflow  models  to  shared  memory 
models  —  obtained  by  “inverting”  the  equations  that  define  the  interpretation 
to  obtain  something  like  an  inverse  interpretation  whose  dual  maps  dataflow 
structures  to  shared  memory  structures  —  had  to  be  introduced.  By  reducing 
the  class  of  structures  that  correspond  to  a  specification  to  a  singleton,  the 
necessity  of  finding  an  appropriate  mapping  from  dataflow  structures  to  shared 
memory  structures  is  eliminated:  see  Figure  4.4.  As  a  result,  the  correctness 
proof  is  reduced  to  straightforward  calculation,  requiring  no  creativity  on  the 
part  of  the  prover.  Correctness  proof  construction  is,  therefore,  much  simpler 
and  much  more  straightforward  when  using  the  new  approach  in  place  of  the 
old. 


4.5  Chapter  Summary 

The  essential  difference  between  the  two  techniques  stems  from  regarding  archi¬ 
tectural  specifications  as  mathematical  models  of  the  systems  being  specified, 
rather  than  comparatively  weak  descriptions  of  those  systems.  Since  our  justifi¬ 
cation  for  demanding  that  higher-level  specifications  be  faithfully  interpretable 
in  lower-level  specifications  was  that  an  architectural  specification  should  say 
everything  that  can  truly  be  said  of  the  system’s  architecture  at  a  given  level  of 
abstraction,  it  is  natural  to  demand  that  the  logical  analogues  of  these  specifi¬ 
cations  be  complete  theories.  So,  this  formalization  of  the  connection  between 
architectural  specifications  and  logic  is  arguably  more  natural  for  our  purposes. 
This  is  one  reason  for  regarding  the  approach  of  this  paper  to  be  superior.  An¬ 
other,  more  practical  and  important,  reason  is  that  correctness  proofs  become 
much  simpler,  as  the  example  shows. 

It  should  be  noted  that  this  is  a  relatively  minor  modification  of  the  original 
approach:  specifications  are  stronger,  proofs  of  correctness  are  simpler,  but  the 
basic  idea  of  proving  particular  refinement  steps  correct  by  using  a  library  of 
pre- verified  refinement  rules  remains  the  same.  Ordinary  users  of  our  architec¬ 
ture  specification  tools  see  no  difference  between  the  two  approaches  —  all  the 
refinement  patterns  that  they  are  used  to  using  are  still  valid  —  but  the  burden 
for  those  who  wish  to  extend  the  system  by  validating  new  refinement  patterns 
has  been  considerably  lightened. 

It  should  also  be  noted  that  this  new  approach  cannot  be  directly  applied  to 
all  conceivable  refinement  patterns.  Some  architectural  descriptions  cannot  nat¬ 
urally  be  thought  of  as  specifying  a  single  architectural  structure.  For  example, 
there  are  standard  architectures,  such  as  the  X/Open  Distributed  Transaction 
Processing  (DTP)  architecture  [46],  that  specify  how  various  types  of  compo¬ 
nents  are  composed,  but  do  not  specify  the  number  of  components  of  each  type. 
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Figure  4.4:  New  Proof  Technique  for  Theory  Interpretation 
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In  such  cases,  it  is  much  more  natural  to  think  of  the  standard  as  specifying  a 
class  of  structures.  However,  the  new  approach  can  be  used  to  verify  a  set  of 
simple,  primitive  refinement  patterns  that  generate  the  refinements  in  a  multi¬ 
level  formal  representation  of  X/Open  DTP  in  the  Sadl  language  [28],  as  well 
as  all  the  refinement  patterns  of  our  previous  paper  [26]. 
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Chapter  5 


Correctness  of  Architecture 
Transformation  Rules 

5.1  Introduction 

In  previous  papers  [26,  39],  my  colleagues  and  I  defined  what  it  means  for  a  re¬ 
finement  step  in  an  architecture  hierarchy^  to  be  correct  and  proved  the  correct¬ 
ness  of  a  refinement  pattern  that  says  a  dataflow-style  architectural  description 
consisting  of  two  procedural  components  connected  by  a  dataflow  channel  can 
be  implemented  as  two  procedural  components  and  a  variable  that  is  written 
by  one  procedure  and  read  by  the  other.  This  pattern  is  shown  in  Figure  5.1. 

However,  it  should  be  noted  that  we  did  not  show  that  a  dataflow  channel  can 
always  be  replaced  by  a  shared  variable  in  this  way.  We  proved  that  refinement 
step  shown  in  Figure  5.1  is  always  correct;  we  did  not  prove  that  the  refinement 
step  shown  in  Figure  5.2,  where  the  same  refinement  is  embedded  in  a  more 
complicated  context,  is  always  correct.  In  other  words,  we  did  not  show  that,  if 
an  architecture  hierarchy  is  correct,  then  the  extended  hierarchy  that  results  by 
adding  a  node  in  which  a  chosen  dataflow  channel  has  been  refined  into  a  read 
and  written  variable  is  also  correct.  We  did  not  show  this  for  a  good  reason: 
the  extended  hierarchy  may  not  be  correct.  A  very  simple  example  illustrates 
this  point. 

The  two  architectural  descriptions  shown  in  Figure  5.3  differ  in  that  the 
more  abstract  description  which  is  an  extension  of  description  Di  in  Fig¬ 
ure  5.1,  contains  a  dataflow  channel  C2  that  has  been  replaced  in  the  more 
concrete  description  D2  by  a  shared  variable  V2.  According  to  our  correctness 
criterion  [26],  every  architectural  description  in  a  hierarchy  should  tell  the  whole 

^An  architecture  hierarchy  is  a  collection  of  architectural  descriptions,  at  various  levels 
of  abstraction  and  often  in  a  variety  of  styles,  linked  by  refinement  mappings.  Since  the 
descriptions  are  all  intended  to  describe  the  same  software  architecture,  they  must  paint  a 
consistent  portrait  of  that  architecture.  Consistency  is  guaranteed  by  the  correctness  of  the 
refinement  steps  in  the  hierarchy.  Thus,  a  hierarchy  is  correct  iff  every  refinement  step  in  it 
is  correct. 
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Figure  5-3:  An  Incorrect  Hierarchy 


truth  —  more  precisely,  the  whole  truth  expressible  at  the  level  of  abstraction 
determined  by  the  style  of  the  description  —  about  the  architecture.  Clearly, 
if  description  Figure  5.3  is  telling  the  truth,  then  description  DJ  is  not 

telling  the  whole  truth.  The  language  used  for  D[  has  the  descriptive  power 
to  say  that  the  dataflow  from  ao  to  ai  is  implemented  as  a  shared  variable:  it 
mentions  the  shared  variable  V2.  In  formal  terms,  the  natural  interpretation  of 
the  theory  corresponding  to  the  abstract  description  in  the  theory  correspond¬ 
ing  to  the  concrete  description  —  the  one  that  interprets  dataflow  in  terms  of 
shared  variables,  and  leaves  everything  else  “as  is”  —  is  not  faithful} 


5.2  Composition  versus  Transformation 

5.2.1  Composition 

It  is  easy  to  see  that  the  source  of  the  problem  is  the  mixing  of  dataflow-style  con¬ 
structs  and  shared- variable-style  constructs  in  D[.  In  our  previous  paper  [26], 
we  employed  a  development  methodology  that  avoided  such  non-homogeneous 
architectural  descriptions.  The  basic  idea  was  that  every  dataflow  channel  in 
a  specification  would  be  simultaneously  replaced  by  its  implementation.  This 

2  An  interpretation  >  of  theory  O  in  theory  T  is  a  (total)  mapping  from  sentences  in  the 
language  ^  of  0  to  sentences  in  the  language  of  T  such  that,  for  every  i^’-sentence  (p, 

G  0  =>  €  r 

If,  in  addition,  for  every  i^’-sentence  (^, 

G  r=>  pee 

then  interpretation  is  faithful.  For  more  detail  on  interpretations,  see  the  previous  chapter 
on  how  to  prove  a  mapping  is  a  faithful  interpretation. 
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complex  refinement  would  be  proven  correct  by  showing  it  to  be  an  instance  of 
a  “mega-pattern”  built  from  verified  primitive  refinement  patterns,  using  modes 
of  composition  that  have  been  shown  to  preserve  correctness.  Figure  5.4  illus¬ 
trates  a  simple  case  where  a  refinement  of  dataflow  channel  ci  that  is  correct  in 
isolation  and  a  refinement  of  dataflow  channel  C2  that  is  also  correct  in  isolation 
are  composed  to  obtain  a  correct  refinement  of  the  full  dataflow  description. 

Despite  the  intuitive  appeal  of  this  compositional  approach,  there  are  serious 
difficulties  in  attempting  to  characterize  the  modes  of  composition  that  preserve 
correctness.  It  is  instructive  to  see  why  Moriconi  and  Qian’s  attempt  to  work 
out  the  formal  details  [25,  Section  8]  is  unsatisfactory. 

First,  their  “definition”  of  h  U  h  is  incomplete.  They  write 

More  precisely,  if 

h  ■  &i  -t  and  J2 :  02  -t  @2 
are  faithful  interpretations,  then  we  want 

/i  U  /2  :  01  U  02  O'l  U  02 

to  be  a  faithful  interpretation.  (The  union  of  two  theories  is  the 
deductive  closure  of  the  set-theoretic  union  of  the  theories.) 

But  how  is  the  mapping  h  Uh  defined  on  sentences  that  are  consequences  of  the 
union  of  the  two  theories  that  are  not  in  the  union  of  their  consequences?  And 
how  is  it  defined  on  sentences  that  are  not  consequences  of  the  union?  Getting 
the  answers  to  these  questions  right  is  non-trivial.^  Without  the  answers,  it  is 
hard  to  assess  the  merits  of  their  attempt  in  detail. 

Still,  it  is  clear  that  there  is  a  fundamental  difficulty  with  their  account. 
What,  according  to  Moriconi  and  Qian,  is  wrong  with  composing  the  correct 
refinement  of  Figure  5.1  with  the  trivially  correct  identity  refinement  on  the  rest 
of  the  system,  to  obtain  the  refinement  shown  in  Figure  5.3?  Simply  that  their 
second  “general  condition”  for  correct  composition 

It  must  not  be  possible  to  infer  new  facts  about  the  composite  ab¬ 
stract  architecture  from  the  composite  concrete  architecture.  That 
is,  for  language  L\  of  0i  and  L2  of  02,  if 

F  is  a  sentence  of  L\  U  L2 


and 

0lU0ih/(F) 

then  we  must  prove  that 

/(0i)U  7(02)  H  7(F) 

^See  Section  5.4.2- 
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Figure  5.4:  Composing  Correct  Refinements 
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is  violated.  But  this  condition  is  just  a  straightforward  restatement  of  the  re¬ 
quirement  that  the  interpretation  corresponding  to  the  composite  refinement  is 
faithful.  They  claim  that  this  condition  is  satisfied  in  their  one  specific  example, 
which  was  extracted  from  the  compiler  architecture,  because  the  subarchitec¬ 
tures  “share  no  interface  points”.  If  they  were  right,  the  proof  that  a  particular 
instance  of  this  mode  of  composition  preserves  correctness  could  be  reduced  to 
a  simple  check  that  there  are  no  common  interface  points  in  the  domains  of 
the  several  refinements  being  composed.  Yet  the  incorrect  refinement  step  in 
Figure  5.3  shows  that  having  no  shared  interface  points  is  not  sufficient  to  guar¬ 
antee  faithfulness  of  this  mode  of  composition.  Moriconi  and  Qian  thus  failed  to 
provide  a  single  non-trivial  exsimple  of  a  mode  of  composition  that  is  guaranteed 
to  preserve  correctness.  If  every  instance  of  composition  requires  a  proof  that 
their  second  “general  condition”  is  satisfied  (i.e.,  requires  a  proof  of  faithful¬ 
ness),  the  fundamental  motivating  notion  of  pre-verifying  the  refinements  and 
modes  of  composition  has  been  abandoned. 

The  difficulties  of  finding  modes  of  refinement  composition  that  preserve 
correctness  has  been  noted  by  other  researchers.  For  example,  Broy  [5,  pp.  3] 
writes 

Traditionally,  compositional  notions  of  specification  and  refinement 
are  considered  hard  to  obtain.  . . .  Finding  compositional  specifica¬ 
tion  methods  and  compositional  interaction  concepts  [for  the  class 
of  systems  dealt  with  in  this  paper]  is  considered  a  difficult  issue. 

Of  course,  Broy  is  concerned  with  the  usual,  more  liberal  notion  of  correct  re¬ 
finement  that  consists  of  “adding  logical  properties”.  His  behavior  refinements 
correspond  to  theory  extensions  that  are  not  necessarily  conservative;  his  inter¬ 
face  and  interaction  refinements  correspond  to  theory  interpretations  that  are 
not  necessarily  faithful.  Since  the  faithfulness  requirement  we  have  imposed  on 
correct  structural  refinement  makes  correctness  proofs  much  more  difficult,  it 
should  not  be  surprising  that  finding  correctness-reserving  modes  of  structural 
refinement  composition  becomes  more  difficult  as  well.  So  the  question  arises:  Is 
there  any  alternative  to  the  compositional  approach  that  offers  similar  benefits. 

5.2.2  Transformation 

While  the  charms  of  the  compositional  approach  are  undeniable,  incremental 
transformation  offers  an  even  more  attractive  alternative.  The  compositional 
approach  is  quite  natural  if  the  objective  is  to  verify  the  correctness  of  a  com¬ 
pleted  hierarchy.  On  the  incremental  approEich,  the  objective  is  to  avoid  in¬ 
troducing  mistakes  during  the  design  process,  rather  than  catching  mistakes 
after  they  have  been  made.  Architectures  are  designed  incrementally  in  prac¬ 
tice,  using  an  architecture  design  tool  —  perhaps  a  CASE  tool,  perhaps  paper 
and’ pencil  —  to  incrementally  elaborate  a  hierarchy.  As  each  design  decision  is 
made,  the  hierarchy  is  transformed  to  reflect  the  current  state  of  the  design.  If 
all  the  transformations  of  the  hierarchy  preserve  its  correctness,  and  the  start- 
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Figure  5.5:  Incrementally  Replacing  Dataflow  Channels  by  Shared  Variables 


ing  point  is  a  trivially  correct  refinement-free  hierarchy,  then  the  completed 
hierarchy  that  eventually  results  is  guaranteed  to  be  correct  by  construction. 

But  on  the  transformational  approach,  non-homogeneous  specifications  can¬ 
not  be  avoided.  For  example,  consider  an  abstract  architectural  description 
containing  two  dataflow  channels,  such  as  Dq  of  Figure  5.5.  It  should  be  possi¬ 
ble  to  replace  one  channel  by  a  shared  variable  without  eliminating  the  option 
of  later  replacing  the  second  by  a  shared  variable  as  well.  At  first  glance,  the 
series  of  architectural  transformations  shown  in  Figure  5.5  may  seem  to  cast 
doubt  on  our  definition  of  correctness,  for  there  is  clearly  nothing  wrong  with 
this  series.  What  the  correctness  of  this  series  actually  shows  is  that,  whatever 
it  means  to  say  that  a  transformation  rule  is  correct,  it  cannot  be  the  case  that 
correct  transformation  is  simply  a  matter  of  correct  refinement.  The  connection 
between  correct  transformation  rules  and  correct  refinement  patterns  must  be 
less  direct. 
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5.3  From  Correct  Refinements  to  Correct  Trans¬ 
formations 

The  first  step  in  establishing  the  connection  between  correct  refinement  and 
correct  transformation  is  to  view  transformations  as  being  applied  to  the  entire 
hierarchy  rather  than  to  the  individual  descriptions  in  the  hierarchy.  Figure  5.6 
shows  the  same  two  transformations  that  were  shown  in  Figure  5.5  from  this 
perspective.  Initially,  the  hierarchy  Hq  consists  of  a  single  level.  This  level 
contains  an  abstract  architectural  description  Dq  of  system  dataflow.  The  first 
transformation  produces  a  more  elaborate  hierarchy  Hi  by  introducing  a  second 
level  of  description,  in  which  one  of  the  dataflow  channels  of  Dq  has  been  re¬ 
placed  by  a  shared  variable.  This  partly  abstract,  partly  concrete  description 
is  a  correct  refinement  of  jDq,  so  Hi  is  a  correct  hierarchy  (i.e.,  every  refinement 
step  in  the  hierarchy  is  correct).  The  second  transformation,  which  produces  hi¬ 
erarchy  H2,  modifies  the  lower-level  description  D[  rather  than  adding  another 
level.  The  completed  concrete-level  description  D2  is  also  a  correct  refinement 
of  the  abstract-level  description  Dq,  making  H2  a  correct  hierarchy.^ Note  that 
H2  is  identical  to  the  hierarchy  produced  by  composition  in  Figure  5.4. 

The  original  refinement  pattern  in  Figure  5.1  thus  corresponds  to  two  trans¬ 
formation  rules,  which  can  be  stated  informally  as  follows. 

(Ti)  If  an  architectural  hierarchy  has  a  maximal  node  containing  a  description 
in  pure  dataflow-style,  then  a  successor  of  that  maximal  node  can  be  added 
that  contains  a  description  in  which  one  of  the  dataflow  channels  of  the 
maximal  node’s  description  has  been  refined  into  a  shared  variable. 

(T2)  If  an  architectural  hierarchy  has  a  maximal  node  containing  a  description 
including  a  dataflow  channel,  and  the  predecessor  of  that  node  contains  a 
description  in  pure  dataflow-style,"^  then  the  maximal  node  s  description 
can  be  replaced  by  a  description  in  which  the  dataflow  channel  has  been 
refined  into  a  fresh  shared  variable. 

And  so  the  connection  between  correct  refinement  and  correct  transformation 
is  now  apparent: 

An  architecture  hierarchy  transformation  rule  is  correct  if  and  only 
if,  whenever  it  is  applied  to  a  correct  hierarchy  (i.e.,  a  hierarchy  in 
which  every  refinement  step  is  correct),  a  correct  hierarchy  results. 

In  short,  correct  transformation  rules  preserve  hierarchy  correctness. 

4The  rationale  for  this  restriction  on  the  style  of  the  predecessor  will  become  clear  when 
this  transformation  is  proven  correct,  in  Section  5.4. 
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Figure  5.6:  Incremental  Replacement:  Another  Perspective 
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5.4  Proving  Transformations  Correct:  two  ap¬ 
proaches 

5.4.1  What  more  is  needed  to  prove  correctness? 

Transformation  Ti,  the  first  of  the  two  transformations  above,  extends  a  hi¬ 
erarchy  by  introducing  an  additional  node,  linked  by  an  additional  refinement 
step.  So  to  say  that  Ti  preserves  correctness  of  hierarchies  simply  means  that 
the  refinement  step  that  is  introduced  is  always  correct.  Transformation  T2 
modifies  an  existing  refinement  step,  so  saying  that  it  is  correct  means  that  the 
modification  preserves  correctness  of  the  refinement  step. 

In  a  previous  proof  of  the  correctness  of  the  refinement  step  in  Figure  5.1  [39, 
pp.  7-8],  the  interpretation  X  determined  by  extending  the  following  basis 
to  every  sentence  of  the  language  of  Do  in  the  standard  way  was  shown  to 
be  a  faithful  interpretation  of  the  theory  of  the  more  abstract  dataflow-style 
architectural  description  Do  in  the  theory  of  the  more  concrete  shared- variable- 
style  architectural  description  Di. 


xo  ^  xo 

Jf^(Procedure)  =  Procedure(xo) 

J^(Channel)  =  Variable(xo) 
jr(ln_Port)  =  CaIl(xo,xi)  A  3x2  Can_Get(xo,X2) 

J^(Out_Port)  =  Call(xo,xi)  A  3x2  Might_Put(xo,X2) 
jr(Can_Carry)  =  Can-Hold  (xo,xi) 

J^(Might-Supply)  =  Might-Put{xo,xi) 

Jf(CanJ\ccept)  =  Can_Get(xo,xi) 

J^( Connects)  =  Writes(xi,xo)  A  Reads(x2,xo) 

X(T)  =  T{xo) 

=  Xo  =  ao 

jf(ai)  =  Xo  =  ai 
X{ci)  =  Xo  =  vi 
X^(ao-oport)  =  xo  =  ao-call 
Jport)  =  Xo  =  ai_call 

Why  can’t  the  faithfulness  of  this  interpretation  be  used  to  prove  that  the 
refinements  introduced  by  transformation  rules  Ti  and  T2  are  correct?  It  is  not 
the  interpretation  that  corresponds  to  these  transformations.  According  to  X 
every  channel  is  implemented  as  a  variable  and  every  connection  is  implemented 
by  reading  and  writing  a  shared  variable.  In  incremental  development,  some 
connecting  channels  remain  connecting  channels. 
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5.4.2  First  approach:  modifying  the  interpretation 

One  approach  to  showing  Ti  is  correct  is  to  modify  the  definition  of  interpre¬ 
tation  in  a  way  that  maintains  faithfulness,  so  as  to  make  it  correspond  to 
Ti.  Ideally,  the  modification  should  preserve  faithfulness  in  general,  not  just 
in  the  particular  case  of  so  that  proving  a  refinement  step  correct  always 
guarantees  that  the  transformation  that  extends  a  hierarchy  by  applying  that 
refinement  to  a  homogeneous  description  in  a  maximal  node  is  also  correct. 

Unfortunately,  well-known  general  results  on  extensibility  of  interpretations 
are  not  applicable  in  this  case.  For  example,  Turski  and  Maibaum’s  “Modular¬ 
ization  Theorem”  [45,  pp.  174]  says  that  an  interpretation  of  theory  0  in  theory 
Y  can  always  be  extended  to  an  interpretation  of  any  conservative  extension  0' 
of  0  in  a  conservative  extension  of  T.  Despite  their  claim  that  this  theorem 
“guarantees  that  an  implementation  of  [an]  extension  [of  an  existing  system] 
will  be  consistent  with  an  implementation  of  the  existing  system,”  it  is  not 
applicable  to  the  sort  of  “extensions”  of  descriptions  under  consideration  here. 
Depending  on  details  of  the  formalization,  the  theory  of  Dq  may  or  may  not  be 
an  extension  of  but  it  is  certainly  not  a  conservative  extension.  Sentences 
made  true  by  the  context,  such  as 

3xo  [  Proc€dure(xo)  A  -ixq  =  ao  A  -ixo  ^  ai  ] 

will  be  included  in  the  theory  of  Dq,  but  not  the  theory  of  Do-  The  example 
Turski  and  Maibaum  use  to  show  that  conservativeness  is  necessary  for  the 
theorem  to  hold  also  shows  that,  even  if  the  interpretation  to  be  extended  is 
faithful,  conservativeness  remains  necessary. 

Since  general  results  on  extensibility  do  not  yield  the  desired  interpretation, 
a  modification  suited  to  our  specific  requirements  must  be  sought.  Changing  the 
definition  of  —  thereby  defining  a  new  interpretation  basis  called  “[1  VJ^”, 
for  reasons  that  the  definition  will  make  clear  —  so  as  to  allow  the  possibility 
of  channels  being  interpreted  as  either  channels  or  shared  variables  is  straight¬ 
forward. 


^[1 V  jr]  =  xo  =  xo 

[1  \/X]  (Procedure)  =  Procedure(xo) 

[1  V (Channel)  =  Channel(xo)  V  Variable(xo) 

[1  VX]  (In.Port)  =  ln.Port(xo,xi) 

V  [  Call(xo,Xi)  A  3x2  Can-Get(xo,X2)  ] 

[1  VJ^  (Out.Port)  =  Out_Port(xo,xi) 

V  [  Call(xo,xi)  A  3x2  Might_Put(xo,X2)  ] 

® If  the  simplified  method  of  proving  correctness  is  used,  or  the  original  method  is  used  and 
“extremal  axioms”  are  added  to  theories,  sentences  such  as 

Vxo  [  Procedure(xo)  — ►  xq  «  ao  V  xq  ■=  ai  ] 

will  be  included  in  the  theory  of  Do  but  not  in  the  theory  of  Dq.  As  a  result,  the  theory  of 
Dq  will  not  be  an  extension  of  the  theory  of  Do- 
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[1  V  Jf]  (CanXarry) 
[1  V  (Might-Supply) 
[1  V  (Can  J\ccept) 

[1  V  (Connects) 

[1  vje]  (T) 

[1  VJ^(ci) 
[1  VX]  (ao-oport) 
[1  Vc;^(aiJport) 
[1  Vje]  (n) 


Can-Carry (xo,xi)  V  Can-Hold(xo,  xi) 
Might_Supply(xo,xi)  V  Might_Put(xo,xi) 
CanJVccept(xo,xi)  V  Can-Get(xo,xi) 
Connects(xo,xi,X2) 

V  [  Writes(xi,xo)  A  Reads(x2,xo)  ] 
T{xo) 

Xo  ^  Vi 
Xo  =  ao-call 
xo  ^  ai-call 

Xo  =  n  for  any  name  n  other  than 
Cl,  ao-oport,  and  ai-iport 


However,  the  resulting  interpretation  is  not  the  interpretation  that  corre¬ 
sponds  to  transformation  Ti,  as  an  example  makes  clear.  Consider  the  applica¬ 
tion  of  Ti  in  Figure  5.6,  which  produces  Hi  from  Ho-  The  intended  interpreta¬ 
tion  of  the  dataflow-language  sentence 


Channel(ci) 


is 


Variable(vi) 


and  the  intended  interpretation  of  the  sentence 

Conn€Cts(ci ,  ao-oport,  ai-iport) 


is 


Writes{ao-call,  vi)  A  Reads(ai_call,  vi) 
According  to  [1  V  these  two  sentences  are  interpreted  as 

Channel(vi)  VVariable(vi) 


and 

Connects(ci, ao-Oport, ai Jport)  V  [  Writes(ao-call,  vi)  A  Reads(ai_call,  vi)  ] 

Interpretation  [IVX]  gets  the  general  facts  right  —  for  example,  it  correctly 
interprets  “there  are  at  least  two  dataflow  channels”  as  “the  total  number  of 
dataflow  channels  and  shared  variables  that  implement  dataflow  is  at  least  two” 
—  but  not  the  particulars. 

Perhaps,  then,  the  interpretation  [J^;  [1  VX\]  that  is  defined  as  follows  on 
atomic  formulas 

r  if  is  a  sentence  in  the  domain  of 

[X;  [1  =  I  otherwise 
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and  is  extended  to  non-atomic  formulas  in  the  standard  way  corresponds  to 
T\.  (This  mode  of  composition  of  interpretations  —  disjunction,  but  with  basic 
facts  treated  specially  —  may  be  something  like  what  Moriconi  and  Qian  in¬ 
tended  for  their  union  operation.)  While  it  is  not  entirely  clear  that  this  is  the 
interpretation  that  naturally  corresponds  to  Ti,  at  least  there  are  no  obvious 
counterexamples  to  that  thesis. 

The  next  step  is  to  find  the  interpretation  that  corresponds  to  transformation 
T2.  The  difference  here  is  that  T2  is  being  used  to  modify  an  interpretation  ^ 
of  a  pure  dataflow  theory  in  a  mixed-style  theory  rather  than  introducing  a  new 
interpretation.  But  the  basic  modification  being  performed,  replacement  of  a 
dataflow  channel  by  a  shared  variable,  is  much  the  same.  If  [J^;  [1  is 

extended  so  that  it  applies  to  every  sentence  in  the  range  of 


[[JT;  [1  VJf]]i !](</.)  =  I 


if  [Jf";  [1  V  Jf]]  is  defined  for 
otherwise 


where  the  notation  1”  is  intended  to  suggest  “defined  everywhere” ,  then  T2 
can  be  thought  of  as  replacing  ^  by  [[J^;  [1  VJt]]il]  the  mapping  that 
sends  the  sentence  (p  to  [[Jf;  [1  Vje]]il]  Again,  at  least  there  are  no 

obvious  counterexamples  to  the  proposition  that  [[J^;  [1  corresponds 

to  T2. 

At  this  point,  an  attempt  could  be  made  to  prove  that  [1  VJt]]  is  a 
faithful  theory  interpretation  and  that,  if  ^  is  a  faithful  theory  interpretation, 
so  is  [[J^;  [1  But,  regardless  of  whether  the  original  method  or  the 

simplified  method  of  proving  faithfulness  is  employed,  it  does  not  seem  possible 
to  straightforwardly  convert  the  proof  that  J^is  faithful  into  the  desired  proofs.® 

This  analysis  suggests  that  there  are  two  fundamental  problems  with  at¬ 
tempts  to  use  a  calculus  of  interpretations  as  a  basis  for  proving  transforma¬ 
tions  correct.  First,  there  is  the  absence  of  a  truly  compelling  argument  that 
any  particular  combination  of  interpretations  naturally  corresponds  to  a  trans¬ 
formation.  No  matter  how  many  modifications  are  made,  there  is  no  guarantee 
that  yet  another  example  that  shows  the  interpretation  fails  to  correspond  to 
the  transformation  will  not  be  found.  Second,  although  the  correctness  of  trans¬ 
formations  seems  to  intuitively  follow  from  the  correctness  of  the  refinements 
that  suggest  them,  there  does  not  seem  to  be  any  simple,  uniform  method  of 
converting  refinement  correctness  proofs  into  transformation  correctness  proofs. 
The  examples  that  inspired  the  modifications  show  that  the  interpretations  that 
correspond  to  these  transformations  must  not  be  standard  —  the  interpretation 

®When  using  the  original  method,  architectural  descriptions  are  treated  as  collections  of 
axioms,  mappings  are  proved  to  be  interpretations  by  proving  the  images  of  the  axioms  of  the 
abstract  theory  from  the  axioms  of  the  concrete  theory,  and  faithfulness  is  proved  by  a  model- 
theoretic  method  that  requires  “inverting”  the  interpretation.  See  our  earlier  paper  [26]  for 
details.  When  using  the  simplified  method,  architectural  descriptions  are  taken  as  specifying 
a  particular  structure,  mappings  are  proved  to  be  theory  interpretations  by  using  the  fact  that 
a  mapping  of  the  theory  of  the  abstract  structure  to  the  theory  of  the  concrete  structure  is 
an  interpretation  if  the  image  of  the  concrete  structure  under  the  abstraction  map  that  corre¬ 
sponds  to  the  mapping  on  sentences  is  isomorphic  to  the  abstract  structure,  and  faithfulness 
is  automatic.  See  my  earlier  paper  [39]  for  details. 
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of  pr6dic8Ltes  Chsnnel,  Connects,  and  so  on,  depends  on  their  arguments  and 
so  neither  of  the  techniques  we  have  developed  for  proving  faithfulness  can  be 
directly  applied.  It  is  not  clear  how  either  the  “inverse  mapping”  of  the  original 
method  or  the  abstraction  mapping  on  models  of  the  simplified  method  can  be 
defined.  In  the  next  section,  an  alternative  approach  to  proving  transformation 
correctness  that  avoids  both  these  problems  will  be  investigated.^ 

5*4-3  Second  approach:  modifying  the  theories 

The  difficulties  in  adapting  Xto  generally  interpret  dataflow  in  terms  of  shared 
variables  flow  from  a  single  source:  the  logical  theories  being  used  to  describe 
the  architectures  are  too  weak  to  distinguish  between  dataflow  channels  that 
get  implemented  as  shared  variables  and  those  that  do  not.  In  terms  of  the 
example  in  Figure  5.6,  the  interpretation  that  Ti  introduces  call  it 
should  act  as  follows: 


^■^(ChanneKci))  =  Variable(vi) 
jr^(Channel(c2))  =  Channel(c2) 

Since  these  sentences  are  being  interpreted  differently  by  ,  there  is  clearly 
some  difference  between  the  two  cases  that  is  not  being  reflected  in  the  logical 
theory.  Rather  than  making  somewhat  ad  hoc  modifications  to  X  to  account 
for  the  difference,  as  in  the  first  approach,  let  us  explore  the  option  of  modifying 
the  logical  theories. 

As  a  first  step,  expand  the  language  of  dataflow  used  to  describe  the 
more  abstract  architecture.  Corresponding  to  the  singulary  predicate  Channel, 
add  two  new  singulary  predicates  Green.Channe!  and  RedXhannel,  and  simi- 
larly  for  all  the  other  predicates  —  In.Port,  Out_Port,  CanXarry,  Might_Supply, 
Can  J^ccept,  and  Connects  —  that  are  re-interpreted  by  X .  Call  this  expanded 
language 

Next,  if  the  original  correctness  method  is  being  used,  extend  the  theory 
Q  of  the  dataflow  description  by  adding  sentences  that  describe  the  particular 
coloring, 

GreenXhannel(c) 

Green_Connects(c,  Pout,Pin) 

Green_ln_Port(pin,  ain) 

Green,0ut-Port(pout5  ^out) 


where  c  is  the  channel  that  gets  implemented  by  the  application  of  Ti ,  pin  and 
Pout  are  the  input  and  output  ports  that  c  connects,  ain  is  the  process  pin  is  a 

^It  will  turn  out  that  [JT;  [1  VJT]]  does  not  correspond  to  Ti,  and  that  [[J^;  [1  VJfr]]il] 
does  not  correspond  to  T2.  The  interpretations  that  correspond  to  these  transformations  do 
not  even  respect  logic.  So  it  is  doubtful  whether  additional  iterations  of  find  a  counterexam¬ 
ple,  then  modify  the  definition  to  eliminate  it”  would  result  in  discovering  correct  definitions. 
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port  of,  and  so  forth,  and 


Red_Channe!(c) 
Red_Connects(c,  Pout.  Pin) 
RedJn.Port(pin,ain) 

Red_Out_Port  (pout ,  aout ) 


for  all  other  channels  c.  The  extension  also  adds  general  color  constraints  that 
relate  colored  and  non-colored  predicates,  sentences  such  as 

Vxo  [  Green_Channe!(xo)  Channel(xo)  ] 


and 


Vxo  [  Red.Channel(xo)  Channel(xo)  ] 


and  also  sentences  such  as 


VxqVxi  Vx2  [  Green_Connects(xo,xi,X2) 

^  Connects(xo,xi,X2)  A  Green_Channel(xo) 

A  3x3  Green_Out_Port(xi,X3)  A  3x3  Green Jn_Port(x2, X3)  ] 


and 

VxqVxi  Vx2  [  RedXonnects(xo,Xi,X2) 

^  Connects(xo,xi,X2)  A  RedXhannel(xo) 

A  3x3  Red>Out.Port(xi,X3)  A  3x3  RedJn_Port(x2,X3)  ] 

Call  this  extension  0^.  Note  that  0^  is  clearly  a  conservative  extension  of  0. 

A  model  21  of  0  can  be  expanded  to  a  model  21+  of  0"^  simply  by  assigning  the 
appropriate  extensions  to  the  new  predicates.  For  example, 

Green.Channel^  =  {c^  } 

and 

RedXhannel^^  =  Channel^  ~  {c^  } 

where  c  is  the  channel  that  is  implemented  by  Ti . 

Alternatively,  if  the  simplified  method  is  being  used,  just  expand  21  to  21+  as 
above,  and  let  0+  be  the  theory  of  21+ .  (Note  that  this  0-^  contains  each  of  the 
sentences  that  was  added  to  0  when  using  the  original  method.)  In  this  case 
too,  0^  is  clearly  a  conservative  extension  of  0. 

Call  this  process  of  adding  either  Green,  or  Red.  to  predicates  of  atomic 
sentences  to  indicate  how  their  arguments  are  being  acted  upon  by  the  trans¬ 
formation  coloring.  For  any  -$f-sentence  let  (/?+,  the  coloring  of  be  the 
^+ -sentence 

pA  f\  Tn 
neN 
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where  N  is  the  set  of  names  that  occur  in  ip  and,  for  any  name  n,  the  sentence 
T„  gives  the  most  explicit  typing  of  the  denotation  of  n.  For  example,  Tc  is 
Green.Channel(c)  if  c  is  the  name  of  the  channel  being  implemented  by  the 
application  of  Ti ,  and  Tc  is  Red.Channel(c)  if  c  is  the  name  of  any  other  channel. 

Observation  Given  the  way  has  beeTi  constweted  froTTi  0,  reyavdless  of 
choice  of  method,  it  is  easy  to  see  that,  for  every  ^-sentence  p, 

ipe  6  e 

Defining  a  standard  interpretation  of  0'^  in  the  language  of  mixed  dataflow 
and  shared  variables  is  now  straightforward.  Let  c  be  the  name  of  the  channel 
being  implemented,  v  be  the  name  of  the  implementing  variable,  Pout  be  the 
name  of  the  output  port  being  implemented,  kwrite  be  the  name  of  the  imple¬ 
menting  write  call,  pin  be  the  name  of  the  input  port  being  implemented,  and 
kread  be  the  name  of  the  implementing  read  call. 


(jjjep  =  Xo  =  xo 


(Procedure)  =  Procedure{xo) 

X,,  (Channel)  =  Channel(xo)  V  Variable(xo) 

Xy  (Green.Channel)  =  Variable(xo) 

(Red.Channel)  =  Channel(xo) 

X^  (ln.Port)  =  ln.Port(xo,xi) 

V  [  Call(xo,xi)  A  3x2  Can_Get(xo,X2)  ] 
(GreenJn.Port)  =  Call(xo,xi)  A  3x2  Can.Get(xo,X2) 

X^.  (Red-ln_Port)  =  ln-Port(xo,xi) 

Xj,  (Out-Port)  =  Out.Port(xo,xi) 

V  [  Call(xo,xi)  A  3x2  Might-Put(xo,X2)  ] 
X^  (Green.Out.Port)  =  Call(xo,xi)  A  3x2  Might.Put(xo,X2) 

X^  (Red.Out.Port)  =  Out.Port(xo,xi) 

X^.  (Can-Carry)  =  Can-Carry(xo,xi)  V  Can-Hold(xo,xi) 

Xj,  (Green.Can.Carry)  =  Can.Hold(xo,xi) 

(Red-Can.Carry)  =  Can-Carry(xo,xi) 
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(Might_Supply)  =  Might-Suppiy(xo, Xi)  V  Might.Put(xo,Xi) 

^  (Green_Might_Supply)  =  Might-Put(xo, xi) 

(Red.Might_Supply)  =  Might_Supply(xo,  xi) 

(CanJVccept)  =  CanJ\ccept(xo, xi)  V  Can.Get(xo,xi) 

Xj,  (GreenXan-Accept)  =  CanXet(xo,xi) 

(Red_Can_Accept)  =  Can_Accept(xo, xi) 

(Connects)  =  Connects(xo,xi,x2) 

V  [  Writes(xi,xo)  A  Reads(x2,xo)  ] 
(GreenXonnects)  =  Writes(xi,xo)  A  Reads(x2,xo) 

X^  (Red-Connects)  =  Connects(xo,xi,X2) 
je;  (T)  =  T(xo) 

(c)  =  Xo  =  V 
(Pout)  —  Xq  —  kvvTite 
(Pin)  —  ^0  “  ^read 

(n)  =  xo  ^  n  for  any  name  n  other  than 

Cj  Poutj  Q-nd  Pout 

Interpretation  X'^  can  now  be  defined,  for  every  ^-sentence  (p,  by 

It  should  be  clear  that  X^ ,  as  defined  above,  is  the  interpretation  that 
corresponds  to  Ti,  but  consideration  of  an  example  will  reinforce  this  point. 
Consider  the  dataflow  language  sentence 

Connects(c,  Pout,  Pin) 

where  c  denotes  the  channel  being  implemented  by  Ti ,  and  pout  and  pin  denote 
the  ports  that  c  connects.  The  result  of  coloring  this  sentence  is 

Connects(c, pout,  Pin)  A  Gr€enXhanneI(c) 

A  3xo  Green-Out_Port(pout,xo)  A  Bxq  GreenJn-Port(pin,  xq) 

Note  that  this  sentence  is  equivalent,  modulo  the  color  and  type  constraints  of 
to 

Green-Connects(c,  Pout,  Pin) 

Applying  X^  to  the  colored  sentence  results  in  the  sentence 

[  Connects(v,kwrite,kread)  V  [  Writes(kwnte,v)  A  Reads(kread,  v)  ]] 

A  Variab!e(v) 

A  3xo  [  Call(kwnte,xo)  A  3xi  Might-Put(kwrite,xo)  ] 

A  3xo  [  Call(kread,xo)  A  3xi  Can_Get(kread,Xo)  ] 
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where  v  denotes  the  implementing  variable,  and  k^rite  kread  denote  the 
implementing  calls.  This  sentence  is  equivalent,  modulo  the  type  constraints  of 
r,  to 

Writes(kwrite,  v)  A  Reads(kread,  v) 


as  desired. 

5.4.4  Proving  and  faithful 

Interpretation  can  be  shown  to  be  a  faithful  interpretation  of  in  the 
theory  T  of  the  mixed  architecture  that  is  introduced  by  the  application  of  Tj 
using  essentially  the  same  proof  used  to  show  that  X  is  a  faithful  interpretation 
of  the  theory  of  the  piece  of  the  dataflow  architecture  that  is  being  implemented 
in  the  theory  of  the  implementing  piece  of  the  shared  variable  architecture.  A 
sketch  of  the  proof  that  X^  faithfully  interprets  the  colored  theory  of  Dq  in  the 
theory  of  D[  illustrates  this  point. 

The  structures  5)o  that  correspond  to  Dq  can  be  formally  defined  as  follows: 

|2)ol  =  {oo,ai,U2,Ci,C2,Po,Pl,P2,P3}  U  Ti  U  T2 
Procedure^®  =  {00,01,02} 

Channel®®  =  {ci,C2} 

Green-Channel®®  =  (ci) 

Red-Channel®®  =  {02} 

In.Port®®  =  {(pi,ai),  (P3,a2>} 

Green -In -Port®®  =  {{pi)<Ji)} 

Red-ln-Port®®  =  {(^3,02)} 

Out_Port®°  =  {{po,ao),{p2,cii)} 

Green-Out-Port®®  =  {{po,cio)} 

Red -Out-Port®®  =  {(P2,ai)} 

Can_Carry®°  =  {(ci,t)  :  t  G  Ti}  U  {{c2,t)  :  t  G  r2} 

Green -Can -Carry®®  =  {(ci,f)  :t€Ti} 

Red-Can-Carry®®  =  {(c2,t)  :  t  G  T2} 

Might-Supply®®  =  {(po?t)  :  f  €  Ti}  U  {(p2,t)  :  *  ^  ^2} 
Green-Might-Supply®®  =  {{po,t)  ^  t  ^  ^1} 

Red-Might-Supply®®  =  {{p2,t)  :teT2} 
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Can_Accept®o  =  {{pi,0  :  t  €  Ti }  U  {{ps, f)  :te  T^} 
Green_Can_Accept^o  =  {{pi^t)  :  t  £  Ti] 

Red_Can_Accept®o  =  {{p^J)  :  t  £  T2} 

Connects^o  =  {(ci,po,Pi),  (c2,P2,P3)} 
Green.Connects^o  _  {{ci,po,Pi)} 

Red_Connects®o  =  {(c2,P2,P3)} 


T)’ 

ao-oport  0 
ai  Jport^o 
ai_oport®o 


♦  55' 

a2-iport  ° 


=  Ti 

=  T2 
=  clq 
=  Gl 
=  02 
=  Cl 

=  C2 
=  P0 
=  Pl 
=  P2 
=  P3 


where  oq,  oi,  02,  Ci,  C2,  po,  P2,  and  ps  are  some  nine  distinct  objects,  none 
of  which  is  a  member  of  the  set  Ti  U  T2.  Similarly,  the  structures  that 
correspond  to  D[  can  be  formally  defined  as  follows: 

l^il  =  {ao,ai,a2,'Gi,C2,A;o,A:i,P2,P3}  UTi  UT2 

Procedure^^  =  {00,01,02} 

Variable®^  =  (vi) 

Channel^i  =  |c2} 

Call®'^  =  {(A:o,Oo),{A:i,oi)} 
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In-Port®'*  =  {{P3,a2)} 
Out.Port®‘  =  {{P2,ai)} 
Can.Hold®'*  =  :  t  &  Ti} 

Can.Carry®*  =  {{c2,t)  :  t  G  T2} 
Might.Put®’  =  {(fcoi*)  *  t  €  Ti} 
Might-Supply®*  =  {{P2,t)  '■  t  ^  T2} 
Can-Get®'*  =  {{fci,t>  :  t  €  Ti} 
Can-Accept®*  =  {(p3,t)  ;  t  €  T2} 
Writes®*  =  {{fco,t^i)} 
Reads®*  =  {(A:i,  vi)} 


=  Ti 

=  T2 

—  Go 
=  ai 
=  02 
=  -^1 
=  C2 


ao-call®^  =  ko 
ai_call^^  =  ki 
ai-oport®o  =P2 
a2  jport^o  =  pz 


where  oq,  oi,  02?  ^2,  ko^  ki^  P2,  and  pz  are  some  nine  distinct  objects,  none 

of  which  is  a  member  of  the  set  Ti  U  T2. 

The  calculation  of  the  value  of  the  abstraction  map  at  2)^  is  very  much 
like  the  calculation  of  at  2)i:  the  Green,  predicates  correspond  to  the  pred¬ 
icates  of  the  language  of  Do^  Red.  predicates  are  the  identity,  and  the  non¬ 
colored  predicates  are  simply  unions.  I  will  show  the  calculation  for  just  one 
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triple  of  predicates,  since  they  are  all  so  similar. 

=  {xo  €  |Di|  :  t=  (Channel)  [xq]} 

=  {xo  €  ID'il  :  Di  1=  Channel(xo)  V  Variab!e(xo)  [xq]} 

=  {vuC2} 

Green.Channel'^  =  {xo  G  |Di|  :  Dj  1=  (Channel)  [xq]} 

=  {xo  G  |Di|  :  D[  1=  Variable(xo)  [xq]} 

=  {^i} 

Red.Channel^  =  {xo  G  |Di|  :  f=  (Channel)  [xo]} 

=  {xo  G  \Tl[  \  :  2)i  1=  Channel(xo)  [xq]} 

=  {^2} 

And,  just  as  in  the  proof  of  it  is  easy  to  see  that  the  function  h  from  |!Oo| 
to  defined  by 

/i(ao)  =  Co 
h{ai)  =  ai 
h{a2)  =  02 
h{ci)  =  Vi 
h{C2)  =  C2 
h{po)  =  ko 

h{pi)  =  ki 

KP2)  =  P2 

Kp^)  =  P3 

h{t)  =  t  for  every  t  G  Ti  U  T2 

is  an  isomorphism.  Hence,  is  faithful. 

That  is  a  faithful  interpretation  of  0  in  T  is  an  immediate  corollary:  for 
every  Jf- sentence  (p, 

ip  G  ©■*■  (Observation  1) 

G  T  is  faithful) 

<=>  €  T  (Definition  of  J(f^) 

This  completes  the  proof  that  Ti  is  correct.  In  contrast  to  the  earlier  attempt 
to  modify  ^  to  deal  with  examples  correctly,  there  can  be  little  doubt  that 
corresponds  to  T\ :  it  was  defined  to  be  the  result  of  applying  to  a  designated 
piece  of  the  dataflow  architecture  —  the  piece  that  was  “colored  green”  —  and 
leaving  the  rest  alone.  In  addition,  note  that  the  bulk  of  the  correctness  proof 
consisted  of  a  proof  that  is  faithful,  which  is  a  straightforward  modification 
of  the  proof  that  J(f  is  faithful. 
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5.4,5  . .  and  similarly  for  r2” 

The  idea  of  expanding  the  theory  and  then  using  X  to  interpret  it  worked  so 
well  for  Ti  that  trying  to  do  the  same  for  is  the  natural  course  of  action.  The 
first  step,  expanding  the  language  of  the  more  abstract  description  by  adding 
the  predicates  Green  ^Channel,  Red.-Channel,  Green_Connects,  Red-Connects,  and 
so  on,  is  exactly  the  same.  The  only  difference  in  this  case  is  that  the  language 
-^that  is  being  expanded  is  not  just  the  pure  language  of  dataflow  plus  names  of 
the  objects  that  make  up  the  particular  architecture.  It  also  contains  some  ad¬ 
ditional  vocabulary  introduced  by  the  earlier  implementation  transformations. 
For  example,  it  may  contain  the  language  of  shared  variables  as  a  result  of  an 
earlier  application  of  Ti  or  T2 .  The  next  step  conservatively  extending  the 
theory  0  of  the  more  abstract  description  to  obtain  Jif^-theory  0^  —  is,  again, 
exactly  the  same  for  T2  as  for  T\.  And,  of  course,  sentences  can  be  colored  and 
Observation  1  continues  to  hold,  just  as  in  the  case  of  Ti . 

But,  in  this  case,  the  theory  T  of  the  more  concrete  description  is  anal¬ 
ogously  extended.®  Just  as  the  channel  in  the  abstract  description  that  the 
transformation  will  implement  must  be  distinguished  from  those  that  are  left 
alone,  the  new  variable  that  is  introduced  in  the  concrete-level  description  must 
be  distinguished  from  those  that  were  already  present.  Again,  coloring  will  be 
employed,  this  time  using  Green,  for  the  freshly  introduced  variable  —  since  it 
corresponds  to  the  “green”  channel  —  and  Yellow,  for  the  pre-existing  variables, 
and  similarly  for  other  types.  Call  the  extended  theory  . 

Now  define  an  interpretation  of  0“^  in  T""  by  slightly  modifying  and 
extending  the  definition  of  Xj,. 


=  Xo  =  Xo 


X^  (Procedure)  =  Procedure(xo) 

X^  (Channel)  =  Channel(xo)  V  Variable(xo) 

Xy  (Green.Channel)  =  Green.Variable(xo) 

X^  (Red.Channel)  =  Channel(xo) 

X^  (Variable)  =  Yellow.Variable(xo) 

J^(ln  -Port)  =  ln.Port(xo,xi) 

V  [  Call(xo,xi)  A  3x2  Can.Get{xo,X2)  ] 

Xc  (Green.ln_Port)  =  Green.Call(xo,xi)  A  3x2  Green.Can-Get(xo,X2) 
X,  (RedJn-Port)  =  ln.Port(xo,xi) 

X  (Call)  =  Yellow.Call(xo,xi) 

X^  (Can.Get)  =  Yellow.Can.Get(xo,xi) 


®The  necessity  of  coloring  T  will  be  demonstrated  below. 
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(Out-Port)  =  Out_Port(xo,xi) 

V  [  Call(xo,xi)  A  3x2  Might_Put(xo,  X2)  ] 
(Green-Out-Port)  =  Green-Call(xo,Xi)  A  3x2  Green-Might-Put(xo,X2) 

(Red-Out-Port)  =  Out_Port(xo,  xi) 

Xy,  (Might-Put)  =  Yellow-Might-Put(xo,xi) 

Xy  (Can_Carry)  =  Can-Carry(xo,xi)  V  Can_Hold(xo,Xi) 

Xy  (Green-Can-Carry)  =  Green-Can-Hold(xo, xi) 

Xy  (Red-Can-Carry)  =  Can-Carry (xo,Xi) 

Xy  (Can-Hold)  =  Yellow -Can-Hold(xo,  xi) 

Xy  (Might-Supply)  =  Might-Supply(xo,xi)  V  Might-Put(xo,  xi) 

Xy  (Green-Might-Supply)  =  Green-Might-Put(xo,xi) 

Xy  (Red-Might-Supply)  =  Might.Supply(xo,xi) 

Xy  (Might-Put)  =  Yellow-Might-Put(xo,xi) 

Xy  (Can-Accept)  =  Can-Accept(xo,xi)  V  Can-Get(xo,xi) 

Xy  (Green-Can-Accept)  =  Green-Can-Get(xo,xi) 

Xy  (Red -Can -Accept)  =  Can-Accept(xo,xi) 

Xy  (Can-Get)  =  Yellow-Can-Get(xo,xi) 

Xy  (Connects)  =  Connects(xo, xi,X2) 

V  [  Writes(xi,xo)  A  Reads(x2,xo)  ] 

Xy  (Green-Connects)  =  Green-Writes (xi  ,xo)  A  Green-Reads(x2,  xq) 

Xy  (Red-Connects)  =  Connects(xo, xi,X2) 

Xy  (Writes)  =  Y€llow-Writes(xo,xi) 

X  (Reads)  =  Yellow-Reads{xo,xi) 

Xy  (T)  =  T(xo) 

Xy  (P)  =  P(Xo,Xi,...  ,Xn-l) 

for  every  other  predicate  P 
of  where  P  is  n-ary 

(c)  =  Xo  ^  V 
(pout)  —  Xq  kwrite 
(Pin)  —  Xq  kread 

(n)  =  xo  ^  n  for  any  name  n  of  ^  other 
than  c,  Pout,  and  pout 

Showing  that  Xy  faithfully  interprets  the  colored  theory  of  D[  in  the  colored 
theory  of  D2  is  very  much  like  showing  that  X^  faithfully  interprets  the  colored 
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theory  of  £>o  in  the  theory  of  D[.  For  example, 

=  {xo  e  |D2 1  :  2)2  N  (Channel)  [xo]} 

=  {xo  e  Pal  :  &2  *=  Channel(xo)  VVariable(xo)  [xo]} 

=  {vi,n2} 

Green-Channel‘^>='’(®=)  =  {xo  €  |2>2l  :  ^'2  -K  (Green.Channel)  [xo]} 

=  {xo  €  ID^I :  3)2  ^  Green_Variable(xo)  [xo]} 

=  {1^2} 

Red.Channel-^x**®"^  =  {lo  €  [Dal  ■'^2^ (Red.Channel)  [xq]} 

=  {xo  e  |2)M  :  ®2  ^  Channel(xo)  [xo]} 

=  0 

Variable-^x®!®^)  ^  €  ISjl  ;  Dj  1=  ^  (Variable)  [xq]} 

=  {xo  e  l^D'a!  :  ^'2  ^  Yellow_Variable(xo)  [xo]} 

=  {t'l} 

and  so  ©i  and  (©2)  indeed  isomorphic.  But  note  that  if  7"  had  not  been 
colored,  the  proof  would  have  broken  down.  The  extension  of  Green.Channel 
in  the  image  of  ©^  under  the  abstraction  map  would  have  been  the  set  of 
all  the  shared  variables  of  ©2  (i.e.,  {ui,U2})  rather  than  just  the  set  of  green 
ones,  {ua}.  Similarly,  the  extension  of  Variable  in  the  image  of  ©2  under  the 
abstraction  map  would  have  been  {ui,U2}  rather  than  just  {ui}. 

All  that  remains  to  complete  the  proof  of  Ta’s  correctness  is  to  define  the 
interpretation  JT  of  6>  in  T  and  prove  that,  if  /  is  a  faithful  interpretation 
of  some  pure  dataflow  theory  S  in  0,  which  was  produced  by  composing  some 
number  of  interpretations  that  correspond  to  transformations,  then  is 

a  faithful  interpretation  of  E  in  T.  The  pattern  of  our  earlier  example  cannot 
be  slavishly  followed,  and  defined  as  X  (V’’^))  because  this  sentence  is  m 

the  language  of  T’' ,  not  the  language  of  T.  Apparently,  what  is  needed  is  some 
way  of  “uncoloring”  The  same  sort  of  examples  that  showed  coloring 

r  was  necessary  for  faithfully  interpreting  0+  show  that  T”  cannot  naturally 
be  faithfully  interpreted  in  T,  i.e.,  that  there  is  no  general  method  for  faithfully 
uncoloring  sentences  in  the  language  of  T”.  In  fact,  even  a  simple  sentence  of 
the  form 

-nYellow_Variable(a) 

might  be  impossible  to  uncolor,  since  there  are  two  ways  a  can  fail  to  be  a 
“yellow”  channel,  by  being  a  non-channel  and  by  being  a  “green”  channel.  But 
“yellow”  and  “green”  channels  are  indistinguishable  except  with  respect  to  color, 
so  simply  changing  Yellow.Variable  to  either  Variable  or  Channel  without  regard 
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to  a  will  violate  faithfulness.  Fortunately,  faithfully  uncoloring  every  sentence 
in  the  language  of  Tis  not  required.  A  restatement  of  the  correctness  criterion 
for  will  make  this  point  clearer. 

For  any  set  of  sentences  in  the  language  of  0,  and  any  mapping  J  of  the 
sentences  in  the  language  of  0  to  sentences  in  the  language  of  T,  J  will  be  said 
to  be  a  A-faithful  interpretation  of  &  in  T  if  and  only  if,  for  every  sentence 
in  A, 


G  0  €  T 

The  usual  notion  of  faithfulness  is  a  special  case  in  which  A  is  the  set  of  all 
sentences  in  the  language  of  0. 

It  follows  directly  from  the  definition  of  Zl-faithfulness  that  the  following  two 
conditions  on  faithful  interpretation  ^  of  theory  E  in  theory  0  and  interpreta¬ 
tion  of  theory  0  in  theory  T  are  equivalent. 

1.  is  a  faithful  interpretation  of  theory  H  in  theory  T. 

2.  y  is  a^r]-faithful  interpretation  of  theory  0  in  theory  T,  where  Tis  the 
set  of  all  sentences  in  the  language  of  E. 

So  it  is  not  necessary  to  faithfully  uncolor  every  sentence  in  the  language  of  , 
only  those  sentences  that  are  ((/(^))'^)  for  some  dataflow  language  sentence 
ij;.  It  seems  likely  that  coloring  cannot  affect  whether  a  sentence  (C/('0))‘^) 
is  a  consequence  of  T^:  it  has  been  shown  that,  for  every  sentence  in  the 
language  of  E, 

i)  e  E  /{'ll))  €  0  C/  is  faithful) 

(^(-0))+  G  0"^  (Observation  1) 

^  is  faithful) 

so  whether  or  not  a  sentence  mentioning  “yellow”  variables,  “green”  variables, 
and  so  on,  is  a  consequence  of  T''  is  entirely  determined  by  whether  some  other 
sentence  that  only  talks  about  channels  and  connections  is  a  member  of  E. 

This  intuition  can  be  confirmed.  For  any  sentence  ip  in  the  language  of  T’' , 
let  ip- ,  the  uncoloring  of  (/?,  be  the  sentence  in  the  language  of  T  that  results 
when  all  colored  predicates  are  replaced  by  their  uncolored  counterparts.  For 
example,  both  the  predicate  Green.Variable  and  the  predicate  Yellow.Variable  are 
replaced  by  the  predicate  Variable.  By  showing  that,  for  every  sentence  *0  in  the 
language  of  E^ 

the  proof  that  T2  is  correct,  with  its  corresponding  ^r]-faithful  interpretation 
JXr  defined  by 

X-{ip)^[X.{/))- 


will  be  complete. 
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Figure  5.7:  Incremental  Replacement  with  Additional  Channel 
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To  make  the  structure  of  the  proof  a  bit  clearer,  an  example,  based  on 
Figure  5.7  —  which  is  similar  to  the  familiar  transformation  of  hierarchies  in 
Figure  5.6,  but  with  an  additional  channel  that  remains  unimplemented  —  will 
be  examined  first.  Consider  a  sentence  of  the  form 

Channel(n) 

where  name  n  is  a  name  that  denotes  a  value  in  the  domain  of  Sq,  the  math¬ 
ematical  structure  that  corresponds  to  description  Bq.  There  are  four  cases  to 
be  considered. 

Case  1:  n  denotes  the  channel  that  is  implemented  by  the  application  o/Ti. 

In  this  case,  coloring  the  sentence  for  the  application  of  Ti  produces 

Channel(n)  A  Green_Channe!(n) 

which,  according  to  the  color  constraints  of  the  expanded  theory  of  5!)o,  is 
equivalent  to 


Green_Channel(n) 

Applying  to  the  colored  sentence  results  in 

[Channe!(m)  V  Variable(m)  ]  A  Variable(m) 

where  name  m  denotes  the  implementing  variable,  which  is  equivalent,  ac¬ 
cording  to  the  type  constraints  of  the  theory  of  2)'/, 

Variable(m) 

Coloring  this  sentence  for  the  application  of  T2  has  no  effect,  since  it  only 
adds  a  logically  redundant  conjunct.  So  applying  ^  yields  a  sentence  equiv¬ 
alent  to 


Yellow.Variable(m) 
which  can  be  uncolored  to  yield 

Variable(m) 

Case  2:  n  denotes  the  channel  that  is  implemented  by  the  application  ofT2. 
Coloring  the  sentence  for  the  application  of  Ti  produces 

Channe!(n)  A  Red_Channe!(n) 

which,  according  to  the  color  constraints  of  the  expanded  theory  of  Dq,  is 
equivalent  to 

Red_Channel(n) 
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Applying  to  the  colored  sentence  results  in 

[Channel(n)  V  Variable(n)  ]  A  Channe!(n) 

which  is  equivalent,  according  to  the  type  constraints  of  the  theory  of  D'/, 
to 

Channel(n) 

Coloring  this  sentence  for  the  application  of  T2  results  in 
Channel(n)  A  GreenXhannel(n) 

which  is  equivalent  modulo  the  color  constraints  of  the  expanded  theory  of 
D”  to 

GreenXhanne!(n) 

Applying  yields 

[Channel(m)  VVariable{in)]  A  Green_Variable(m) 

where  m  denotes  the  implementing  variable,  which  is  equivalent  modulo  the 
color  constraints  of  the  expanded  theory  of  to 

Green_Variable(m) 


Uncoloring  produces 


[  Channel(m)  V  Variable(m)  ]  A  Variable(m) 
which  is  equivalent  modulo  the  type  constraints  of  the  theory  of  5^2  to 

Variable(m) 


Case  3:  n  denotes  the  channel  that  remains  unimplemented. 

Coloring  the  sentence  for  the  application  of  Ti  again  produces 

Channel(ii)  A  Red_Channel(n) 

or,  equivalently, 

Red.Channel(n) 

and  applying  to  the  colored  sentence  results  in 

[Channel(n)  V  Variable(n)  ]  A  Channel(n) 


or 


Channel(n) 
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just  as  in  Case  2.  Coloring  for  the  application  of  To  also  results  in 


Channel(n)  A  Red.Channel(n) 


or 


Red_Channel(n) 


Applying  yields 

[  Channel(n)  V  Variable(n)  ]  A  Channel(n) 


or 


Channel(n) 


Uncoloring  is  thus  unnecessary. 

Case  4'  n  denotes  a  non-channel 

In  this  case,  the  first  coloring  produces 

Channel(n)  A  Tn 

which  is  equivalent,  modulo  the  color  constraints  of  the  expanded  theory  of 
2)o,  to  a  contradiction.  Subsequent  applications  of  the  second  coloring, 
,  and  the  uncoloring  all  preserve  this  property  of  being  equivalent,  modulo 
general  color  and  type  constraints,  to  a  contradiction. 

In  any  case,  uncoloring  a  sentence  of  the  form 

Channel(n) 

in  T"'  yields  a  sentence  in  T,  and  uncoloring  a  sentence  of  this  form  not  in  T’' 
yields  a  sentence  not  in  T.  This  occurs  because,  at  every  stage,  the  sentence  is 
either  mapped  to  its  corresponding  implementing  sentence  or  simply  left  alone 
if  it  is  true,  and  is  immediately  eliminated  as  a  candidate  for  inclusion  in  any 
implementing  theory  if  it  is  false. 

The  proof  that  the  same  is  true  when  the  interpretation  is  replaced 
by  another  interpretation  ^  determined  by  transformations  and  the  predicate 
Channel  is  replaced  by  another  singulary  predicate  P  is  quite  similar. 

Case  1:  n  has  been  implemented  as  m  by  an  earlier  transformation. 

Coloring  ^(P(n))  for  the  application  of  T2  adds  conjuncts  that  are  implied 
by  0,  such  as  Tm,  applying  might  add  Yellow,  to  some  of  the  predicates 
of^(P(n))  and  some  of  the  other  conjuncts,  but  then  uncoloring  removes 
Yellow,  leaving  ^(P(n))  conjoined  with  predicates  that  are  implied  by  T. 
So, 


^(P(n))€6)  ^  (j^i(C/(P(n))r))-€r 

in  this  case. 
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Case  2:  n  denotes  the  channel  that  is  implemented  as  variable  m  by  the  appli¬ 
cation  ofT2. 

Coloring  this  sentence  for  the  application  of  T2  results  in 

P(n)  A  Green_Channel(n) 

which  is  equivalent  modulo  the  color  constraints  of  the  expanded  theory  of 
2)'/  to 

Green_P(n) 

Applying  yields 

Green-(jftP(n)))  A  Green.Variable(m) 

where  Green.(j^(P(n)))  is  the  result  of  replacing  every  predicate  Q  of  JftP(n)) 
for  which  a  predicate  Green.Q  has  been  introduced  by  Green.Q.  Uncoloring 
produces 

J^^P(n))  A  Variable(m) 

where  the  second  conjunct  is  implied  by  T.  So,  by  faithfulness  of  the  original 

X, 

/(P(n))  €  ©  ^  ^ 

in  this  case  as  well. 

Case  3:  n  denotes  a  channel  that  remains  unimplemented. 

Coloring  for  the  application  of  T2  also  results  in 

P(n)  A  Red_Channel(n) 


or 

Red_P(n) 


Applying  yields 


J^P(n))  AChannel(n) 

Uncoloring  is  again  unnecessary,  and  so  once  again 

/(P(ii))  €©<==>  (,^(C/(P(n)))‘^))"  e  ^ 

Case  4:  n  denotes  a  non-channel 

Either  the  type  constraints  of  T  require  that  the  argument  of  P  denotes 
a  channel,  or  they  forbid  that  the  argument  of  P  denotes  a  channel.  If 
the  former,  there  is  equivalence  to  a  contradiction  after  coloring,  which  is 
maintained  by  and  uncoloring.  If  the  latter,  then  ^(P(n)  is  unaffected 
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by  the  application  of  T2,  and  it  will  be  a  member  of  T  iff  it  is  a  member  of 
6.  So,  in  this  last  case,  as  in  all  the  others, 

/(P(n))e6  ^  (j^i((/(P(n)r))- er 

Essentially  the  same  argument  works  for  multinary  predicates,  and  ulti¬ 
mately  for  sentences  in  general,^  but  the  notation  becomes  more  complicated 
and  the  number  of  cases  to  be  considered  increases.  Ignoring  details,  it  pretty 
much  boils  down  to  the  fact  that  coloring  has  no  effect  on  membership  in  the 
theories  that  correspond  to  the  descriptions,  because  the  conjuncts  that  are 
added  due  to  coloring  are  all  implied  by  the  relevant  theories,  and  so  either 
implements  according  to  (which  is  faithful)  or  doesn’t  do  anything  (which  is 
also  faithful).  Since  this  was  our  a  priori  reason  for  thinking  T2  is  correct,  the 
proof  can  be  considered  a  formalization  of  that  intuition. 

Just  as  in  the  case  of  the  proof  of  the  correctness  of  Ti,  this  proof  has  several 
advantages  over  a  proof  produced  by  ad  hoc  modification  of  First,  there  is 
no  doubt  that  interpretation  corresponds  to  T2,  since  it  was  defined  as 
applying  cXf  to  the  appropriately  colored  piece  of  the  architecture.  Second,  the 
correctness  of  T2  followed  from  the  faithfulness  of  in  straightforward,  albeit 
tedious,  fashion. 


5.5  The  Main  Results 

Re-examining  the  definitions  of  and  the  proof  that  is  faithful, 
and  the  proof  that,  if  ^  is  faithful,  then  so  is  will  reveal  that  the 

same  constructions  could  be  used  with  another  interpretation  in  place  of  Jt, 
provided  corresponds  to  some  simple  implementation  pattern^®  in  the  same 
way  that  corresponds  to  the  implementation  pattern  in  Figure  5.1.  Thus, 
what  has  actually  been  shown  by  the  arguments  above  is 

Theorem  If 

1.  y  is  the  faithful  interpretation  that  corresponds  to  a  correct  simple  imple¬ 
mentation  pattern  in  the  same  way  that  corresponds  to  the  refinement 
pattern  in  Figure  5.1, 

2.  the  architectural  description  in  a  maximal  node  in  a  correct  architecture 
hierarchy  contains  a  subarchitecture  that  matches  the  abstract  description 
of  the  pattern,  and 

3.  the  entire  architectural  description  of  the  maximal  node  is  in  the  same 
style  as  the  abstract  description  of  the  pattern, 

®More  precisely,  induction  on  formulas  is  employed.  Variables  are  treated  by  assigning 
them  values,  formulas  containing  free  variables  are  interpreted  as  if  the  variables  were  the 
names  of  those  values.  By  generalizing  over  all  assignments,  the  induction  is  completed. 

^^Intuitively,  a  simple  implementation  pattern  is  one  that  says  a  connector  or  component  of 
some  type  can  always  be  replaced  by  some  structure  composed  of  components  and  connectors. 
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then  the  transformation  rule  that  extends  the  hierarchy  by  adding  a  successor 
to  the  maximal  node  containing  a  description  in  which  the  subarchitecture  is  re¬ 
placed  by  the  concrete  description  of  the  refinement  pattern Jand  all  else  remains 
unaltered)  is  correct,  with  corresponding  interpretation  , 

and 

Theorem  If 

L  y  is  the  faithful  interpretation  that  corresponds  to  a  correct  simple  imple¬ 
mentation  pattern  in  the  same  way  that  X  corresponds  to  the  refinement 
pattern  in  Figure  5.1, 

2.  the  architectural  description  in  a  maximal  node  in  a  refinement  hierar¬ 
chy  contains  a  subarchitecture  that  matches  the  abstract  description  of  the 
pattern, 

3.  the  predecessor  of  the  maximal  node  contains  a  description  with  the  same 
subarchitecture,  and 

4.  the  entire  architectural  description  of  the  predecessor  is  in  the  same  style 
as  the  abstract  description  of  the  pattern, 

then  the  transformation  rule  that  modifies  the  hierarchy  by  replacing  the  descrip¬ 
tion  in  the  maximal  node  by  a  description  in  which  the  concrete  description  of 
the  refinement  pattern  is  substituted  for  the  subarchitecture  Jand  all  else  remains 
unaltered)  is  correct,  with  corresponding  interpretation  . 

This  pair  of  results  reduces  the  problem  of  verifying  the  pair  of  transfor¬ 
mations  that  corresponds  to  a  simple  implementation  pattern  to  verifying  the 
pattern  “in  isolation” ,  a  problem  that  has  already  been  shown  to  be  quite  feasi¬ 
ble.  The  fundamental  problems  with  the  compositional  approach  uncertainty 
whether  the  composite  interpretation  actually  corresponds  to  the  transforma¬ 
tion  and  having  to  prove  that  a  variety  of  modes  of  interpretation  composition 
preserve  faithfulness  —  have  been  completely  avoided. 


5.6  Increasing  Formality 

A  question  that  the  statement  of  the  results  and  the  arguments  supporting  them 
immediately  raises  is:  Why  are  both  the  results  and  the  arguments  stated  so 
informally?  The  reason  is  that  they  rely  on  an  intuitive  notion  of  what  a  refine¬ 
ment  pattern  is.  The  particular  patterns  used  as  illustrations  were  presented 
by  drawing  pictures  of  them,  but  these  pictures  have  no  precise  semantics  and 
so  the  arguments  relied  on  an  informal,  intuitive  understanding  of  what  they 

In  Sadl,  the  formal  architectural  description  language  we  have  developed  [28], 
refinements  can  be  thought  of  as  having  the  form 
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An  architectural  description  that  matches  pattern  IJ 
and  satisfies  constraints  A 
can  be  refined  to  a  description  that  matches  pattern 
and  satisfies  constraints 


For  example,  one  of  our  earlier  papers  [26,  Pattern  3]  contains  the  following  re¬ 
finement  for  merging  shared  variables:  an  architectural  description  that  matches 
the  pattern^  ^ 


Procedure [QQpOO  -> 

Qal:  Procedure [QQplO  ->  QQpll] 
Qa2:  Procedure  [®(ap20  ->  Q@p21] 
Qvl:  Variable [Qt] 

Qv2:  Variable [Qt] 

QcO:  ASSERTION  =  Writes (QaO,  Qvl) 
Qcl:  ASSERTION  =  Reads (Qal,  0vl) 
Qc2:  ASSERTION  =  Writes (Qal,  0v2) 
Qc3:  ASSERTION  =  Reads (Qa2,  Qv2) 
QOrest 


can  be  refined  to  a  description  that  matches  the  pattern 


QaO:  Procedure [QQpOO  ->  QQpOl] 
Qal:  Procedure [QQplO  ->  QQpll] 
Qa2:  Procedure [@0p2O  “>  QQp21] 
Qv:  Variable [Qt] 

OcO:  ASSERTION  =  Writes (QaO,  Qv) 
Qcl:  ASSERTION  =  Reads (Qal,  Qv) 
Qc2:  ASSERTION  =  Writes (Qal,  Qv) 
Qc3:  ASSERTION  =  Reads (Qa2,  Qv) 
QQrest 


provided  certain  additional  constraints  on  the  architectural  descriptions  are  sat¬ 
isfied. 

One  reason  this  pattern  cannot  be  applied  without  requiring  satisfaction  of 
additional  constraints  is  that  collapsing  the  two  variables  into  one  might  intro¬ 
duce  an  additional  dataflow  path  from  procedure  ao  to  procedure  a2.  However, 
this  additional  dataflow  will  not  occur  if,  whenever  vi  is  written  by  ao,  V2  is 
written  by  ai  before  V2  is  read  by  a2.  A  sufficient  condition  that  guarantees 
this  temporal  property  is  that  the  procedures  are  run  sequentially:  first  ao, 
next  ai,  and  finally  a2.^^  One  way  of  sequentially  adding  this  constraint  to  the 
refinements^  is  to  include  it  as  part  of  the  concrete  pattern,  as  follows. 

^^The  notation  is  essentially  self-explanatory  once  you  know  that  terms  that  begin  with  “fi” 
are  pattern  variables,  the  SADL-equivalent  of  the  metavariables  in  logical  formulas,  and  that 
pattern  variables  beginning  with  “fiO”  are  matched  with  collections  of  subtrees  of  the  abstract 
syntax  tree  rather  than  individual  subtrees. 

Note  that  this  assumes  that  Writes  means  does  write,  not  can  write. 

^^Explicitly  adding  constraints  at  the  concrete  level  is  quite  appropriate  if  the  refinement 


80 


flaO:  Procedure [QQpOO  ->  00pOl] 
flal :  Procedure [QSplO  ->  QQpll] 

Qa2:  Procedure [Q0p2O  ->  0Qp21] 
flv:  Vzjriable[Qt] 
acO:  ASSERTION  =  Writes (aaO,  Ov) 
acl:  ASSERTION  =  Reads (aal,  av) 
ac2;  ASSERTION  =  Writes (aal,  av) 
ac3:  ASSERTION  =  Reads (aa2,  av) 

ac4:  ASSERTION  =  Starts.Af ter.Finish.Of (aal ,  aaO) 
ac5;  ASSERTION  =  Starts_After_Finish_Of (aa2,  aal) 

®Qrest 

With  this  modification,  it  is  easy  to  prove  that  this  refinement  is  correct  in 
isolation,  i.e.,  when  QQrest  is  matched  to  the  empty  set  in  both  patterns. 

But  it  is  easy  to  see  that  further  restrictions  are  necessary  when  the  pattern 
is  applied  in  context.  The  problem  is  that  procedures  other  than  ao,  ai,  and  a2 
may  be  reading  or  writing  vi  or  V2  —  e.g.,  one  of  the  two  variables  may  have 
been  introduced  by  collapsing  two  other  variables  and  so  collapsing  vi  and 
V2  may  introduce  additional  dataflow  paths  involving  those  other  procedures. 
One  or  more  additional  constraints,  say 

Vx  [  Procedure(x)  A  Writes(x,  Vi)  ^  x  =  ao  ] 

Vx  [  Procedure(x)  A  Reads(x,  vi)  x  =  ai  ] 

Vx  [  Procedure(x)  A  Writes(x,  V2)  — x  ^  ai  ] 

Vx  [  Procedure(x)  A  Reads(x,  V2)  x  =  a2  ] 

must  be  true  of  the  abstract  description  to  ensure  that  no  additional  dataflow 
will  be  introduced  by  the  variable  collapse. It  can  now  be  shown  that  the  re¬ 
finement  is  correct,  in  the  following  sense:  if  an  architectural  description  matches 
the  first  pattern  above,  implies  the  four  additional  conditions  listed  above,  and 
is  consistent  with  the  order-of-execution  constraints  added  to  the  second  pat¬ 
tern,  then  it  can  be  correctly  refined  to  a  description  that  matches  the  modified 
second  pattern. 

This  example  illustrates  the  sort  of  complexities  that  can  arise  in  verifying 
refinement  patterns  more  complicated  than  the  simple  implementation  patterns 
considered  in  this  paper.  In  particular,  it  shows  that,  in  order  to  turn  Results  1 
and  2  into  real  theorems,  a  full  formalization  of  refinements  will  be  required, 
including  a  precise  definition  of  simple  implementation  pattern,  and  that,  as 
a  result,  the  statement  of  the  theorems  is  liable  to  be  somewhat  more  com¬ 
plex  than  the  informal  statement  of  the  results  of  this  paper  might  suggest. 
If  the  ultimate  goal  is  to  automatically  generate  correct  transformations  from 
any  refinement  pattern  that  has  been  proven  correct  in  isolation,  some  manner 

is  being  used  to  generate  a  more  concrete  description  from  the  abstract  description,  but  is 
less  appropriate  if  the  objective  is  to  check  the  correctness  of  existing  hierarchies  where  the 
constraints  may  merely  be  implied  by  some  other  explicit  constraints. 
i^These  conditions  are  merely  sufficient  for  correctness,  not  necessary. 
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of  automatically  generating  the  additional  conditions  that  must  be  satisfied  is 
needed. 
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Chapter  6 


Checking  Correctness  of 
Refinement  Steps 

6.1  Motivation 

The  process  of  specifying  an  architecture  often  begins  by  providing  a  very  high- 
level  description  of  it.  This  description  characterizes  the  architecture  in  terms 
of  a  few  abstract  components,  perhaps  the  principal  functions  the  system  must 
perform  and  some  data  stores.  These  components  are  linked  by  abstract  con¬ 
nectors,  perhaps  indicating  dataflow  or  control  flow  relationships  among  the 
components.  This  abstract  description  provides  an  easily  understood  overview 
of  the  entire  system  architecture,  but  omits  so  much  detail  that  it  provides  rel¬ 
atively  little  guidance  to  someone  charged  with  implementing  the  architecture 
using  programming-language-level  and  operating-system- level  constructs.  So 
the  abstract  description  must  be  successively  reflned  —  with  complex  compo¬ 
nents  and  connectors  decomposed  into  simpler  parts,  and  abstract  specifications 
of  operations  and  relationships  replaced  by  more  concrete  specifications  un¬ 
til  an  appropriate  amount  of  detail  has  been  added.  It  usually  is  desirable  to 
continue  the  refinement  until  implementation-level  constructs  have  replaced  all 
the  abstractions. 

Alternatively,  architecting  a  system  can  consist  of  assembling  instances  of 
reusable  component  and  connector  types  selected  from  a  library.  Such  libraries 
effectively  make  implementation-level  more  abstract,  and  reduce  the  conceptual 
gap  between  the  requirements  specification  and  the  implemented  architecture. 
Nevertheless,  combining  a  large  number  of  components  and  connectors  in  com¬ 
plex  ways  can  easily  result  in  an  architecture  that  is  hard  to  understand  and 
analyze.  So,  it  is  desirable  to  generate  more  easily  comprehensible  abstract 
representations  of  the  implementation-level  architecture. 

In  either  case,  the  end  product  of  the  architecting  process  is  typically  a  col¬ 
lection  of  architectural  descriptions,  at  different  levels  of  abstraction  and  often 
in  different  styles  [10].  The  more  abstract  descriptions  are  linked  to  the  more 
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concrete  descriptions  by  interpretation  mappings.  An  interpretation  mapping 
says  how  the  abstractions  are  implemented.^  It  sends  each  sentence  in  the  lan¬ 
guage  of  the  abstract  description  to  a  corresponding  sentence  in  the  language 
of  the  concrete  description.  For  example,  the  fact  that  some  component  a  is 
implemented  by  components  ai,a2, . . .  ,an  would  be  indicated  by  mapping  the 
sentence 


Component(a) 


to  the  sentence 

Component{ai)  A  Component(a2)  A  ...  A  Component(a„) 

The  collection  of  architectural  descriptions  and  interpretation  mappings  that 
compose  the  complete  architectural  specification  is  called  an  architecture  hier¬ 
archy. 

There  are  many  advantages  to  formalizing  refinement  and  abstraction  in 
system  development:  a  library  of  refinement  or  abstraction  transformations 
provides  a  “corporate  knowledge  base”  of  standard,  or  preferred,  development 
patterns;  mechanizing  the  application  of  these  transformations  lessens  the  like¬ 
lihood  of  clerical  errors  during  the  development  process;  reuse  of  the  transfor¬ 
mations  will  result  in  greater  validation  of  the  patterns  they  codify,  and  so  on. 
But  one  of  the  most  fundamental  advantages  of  formalization  is  that  it  allows 
the  average  developer  to  produce  abstraction  hierarchies  that  are  guaranteed 
to  be  consistent.  In  other  words,  the  use  of  verified  transformations  in  the 
development  process  will  guarantee  that  abstractions  accurately  characterize 
implementations,  albeit  more  abstractly.  A  verified  refinement  transformation 
is  one  that  has  been  proven  to  produce  a  correct  implementation  of  whatever  it 
is  applied  to.  A  verified  abstraction  transformation  is  one  that  has  been  proven 
to  produce  a  correct  abstraction  of  whatever  it  is  applied  to. 

Even  when  attention  is  restricted  to  the  case  of  architectures,  there  is  some 
debate  as  to  exactly  what  correct  should  mean.  We  have  proposed  a  somewhat 
stricter-than-usual  criterion  for  correctness  [26],  while  others  have  argued  that 
the  standard  criterion  is  preferable  [35].  For  present  purposes,  any  reasonable 
criterion  will  do  perfectly  well.  By  a  reasonable  criterion,  I  mean  one  that 
characterizes  correctness  in  terms  of  preservation  of  consequences.  The  standard 
correctness  criterion  is  that  every  consequence  of  the  abstract  description  must 
be  a  consequence  of  the  concrete  description  as  well.  More  precisely,  for  every 
sentence  v?  in  the  language  of  the  abstract  description, 

e\=  if  Aif) 

where  &  is  the  logical  theory  that  formalizes  the  abstract  description,  0'  is 
the  theory  that  formalizes  the  concrete  description,  and  J^is  the  interpretation 

^For  more  details  on  characterizing  implementation  steps  using  interpretation  mappings, 
see  our  earlier  paper  [26]. 
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mapping  that  links  the  two  theories.^  A  mapping  that  satisfies  this  condition 
is  called  an  interpretation  of  0  in  ©' .  Our  proposed  stronger  criterion  replaces 
the  conditional  with  a  biconditional,  i.e.,  requires  that  the  interpretation  map¬ 
ping  be  a  faithful  theory  interpretation.  One  might  also  employ  weaker-than- 
standard  criteria,  where  only  some  consequences  of  the  theory  —  properties  of 
special  interest  —  need  be  preserved. 

What  all  these  criteria  have  in  common  is  that  they  justify  the  use  of  formal 
reasoning  about  the  architecture  based  on  the  more  abstract  descriptions.  If 
some  sentence  is  shown  to  be  a  formal  consequence  of  the  abstract  architectural 
theory,  the  concrete  theory  is  known  to  correctly  implement  the  abstract  theory, 
and  the  sentence  is  among  those  that  the  correctness  criterion  guarantees  are 
preserved  by  the  implementation,  then  the  sentence  is  known  to  be  a  conse¬ 
quence  of  the  concrete  theory  as  well.  It  is  correctness  guarantees  that  link  the 
results  of  abstract  analyses  to  the  real  world. 

The  usual  approach  to  producing  a  correctness  guarantee  is  restricting  the 
architect  to  the  use  of  verified  transformations.  This  approach  suffers  from  a 
problem,  in  practice.  Even  given  a  fairly  mature  library  of  verified  transfor¬ 
mations,  it  would  hardly  be  surprising  if  an  architect  found  himself  unable  to 
perform  a  certain  refinement  or  abstraction  step  that  he  believed  to  be  correct 
because  the  required  transformation  has  not  been  included  in  the  library.  Ex¬ 
pecting  the  typical  system  architect  to  produce  a  formal  proof  that  the  step  is 
correct  is  unrealistic,  yet  the  presence  of  a  single  unverified  implementation  step 
in  the  hierarchy  voids  the  correctness  guarantee  provided  by  the  restriction  to 
verified  transformations.  Is  there  any  way  to  allow  the  user  to  include  such  arbi¬ 
trary  steps  in  the  development  of  the  architecture  hierarchy,  while  maintaining 
a  correctness  guarantee? 


6.2  Proof-carrying  Architectures 

Our  answer  to  this  question  is  based  on  the  notion  of  checking  the  correctness 
of  steps  in  architecture  hierarchy  development.  By  checking,  I  mean  automati¬ 
cally  performing  some  calculation  that  shows  the  step  is  correct.  Checking  can 
be  substantially  simpler  than  verification,  because  it  is  focused  on  a  particular 
step.  Verifying  a  transformation  means  showing  that  it  always  produces  cor¬ 
rect  results,  while  checking  a  trsuisformation  step  means  showing  that  a  correct 
result  was  obtained  in  one  specific  case.  Thus,  checking  entirely  avoids  the 
sometimes  difficult  problem  of  characterizing  the  preconditions  required  for  the 
transformation  to  produce  correct  results  [41]. 

Our  intital  approach  to  checking  transformation  steps  was  inspired  work  by 
George  Necula  and  Peter  Lee  on  compilers  that  generate  proof-carrying  code 
(PCC)  [30].  Their  basic  idea  is,  rather  than  attempting  to  prove  that  the  trans¬ 
formations  performed  by  a  compiler  always  produce  code  with  certain  desired 

^Our  earlier  paper  [26]  explains  how  to  formalize  architectural  descriptions  as  logical  the¬ 
ories.  Since  architectural  description  languages  are  largely  declarative,  the  process  is  quite 
straightforward . 
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Figure  6.1;  Abstract  SDTP  Architecture  —  components  linked  by  secure  chan¬ 
nels 

properties,  to  generate  a  purported  formal  proof  that  the  compiled  code  has 
those  properties  as  part  of  the  code  generation  process.  The  purported  proof 
can  then  be  checked  and,  if  it  turns  out  to  be  a  correct  proof,  it  follows  that  the 
generated  code  has  the  desired  properties.  Thus,  the  emphasis  is  shifted  from 
showing  that  compiler  transformations  are  correct  in  general  to  checking  that 
they  produced  correct  results  in  individual  cases. 

The  application  of  this  idea  to  architectural  transformation  is  straightfor¬ 
ward.  At  some  abstract  level,  the  architectural  description  is  proven  to  guar¬ 
antee  that  the  architecture  has  some  desirable  property,  tt.  The  interpretation 
mapping  J^that  sends  abstract-level  sentences  to  their  implementations  can  also 
be  applied  to  the  proof  of  tt.  If  the  image  of  the  proof  under  the  implementa¬ 
tion  mapping  turns  out  to  be  a  correct  proof  that  the  implementation  has  ./(tt), 
then,  of  course,  the  implementation  has  J^(7r).  Checking  the  transformed  proof 
can,  therefore,  provide  the  desired  correctness  guarantee. 


6.3  An  Example:  secure  distributed  transaction 
processing 

The  idea  of  proof-carrying  architectures  can  be  illustrated  by  consideration  of 
an  example,  based  on  our  development  of  software  architectures  for  secure 
distributed  transaction  processing  (SDTP)  [27].  These  architectures  extend 
X/Open’s  standard  DTP  architecture  [46]  by  enforcing  a  simple  “no  read  up, 
no  write  down”  security  policy.  Figure  6,1  depicts  an  abstract  architecture 
for  SDTP.  The  boxes  are  the  components  of  the  architecture:  the  Application 
(labeled  “ap”),  some  number  of  Resource  Managers  (labeled  “rm”),  and  a  Trans¬ 
action  Manager  (labeled  “tm”).  The  components  are  linked  by  secure  channels, 
indicated  by  the  heavy  doubleheaded  arrows  that  make  up  the  interfaces  between 
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{1} 

{2} 

{3} 

{4} 

{5} 

{1} 

{3} 

{1.3} 

{4} 

{2.4} 

{5} 

{2,4,5} 

{1,2,3,4,5} 
{1.2,  3, 4.5} 


1.  (Vd  :  Labeled-Dat3)[Flows(d,rm,ap) 

— ►  Carries{secure-ar_channe!,  d,  rm’s-ar_port,  ap’s-ar.ports(rm))] 

Axiom  describing  specific  architecture 

2.  Port-Of(ap’sjr.ports(rm),ap)  Axiom  describing  specific  architecture 

3.  (Vc  :  Secure-Channel)(Vd  :  Labeled-Data) (Vx  :  Output-Port) 

(Vy  :  lnput-Port)[Carries(c,d,x,y)  -4  iabel(d)  £  clearance(y)] 

Axiom  characterizing  secure  channels 

4.  (Va  :  Component)(Vy  ;  Input-Port) [Port-Of(y,  a)  clearance(y)  <  clearance(a)] 

Axiom  constraining  port  clearances 

5.  {Vsi,S2,S3  ;  Security -Labe!) [si  <  Sa  A  S2  <  S3  -4  Si  <  S3] 

Axiom  specifying  transitivity  of  security  label  ordering 

6.  Flows(do,  rm,  ap)  Carries(secure-ar_channel,  do,  rm’s-ar-port,  ap’s-ar.ports(rm)) 

Universal  instantiation  (1) 

7.  Carries(secure_ar_channe!,  do,  rm’s-ar_port,  ap’s-ar_ports(rm)) 

label(do)  <  clearance{ap’s-ar-ports(rm)) 

Universal  instantiation  (3) 

8.  Flows(do,rm,ap) label(do)  <  clearance{ap’s.ar.ports(rm)) 

Tautological  consequence  (6,7) 

9.  Port-Of(ap's-ar-ports(rm),ap)  ^  dearance(ap's.ar-ports(rm))  <  c!earance(ap) 

Universal  instantiation  (4) 

10.  cIearance(ap's-ar_ports(rm))  <  clearance(ap)  Tautological  consequence  (2,4) 

11.  label(do)  <  clearance{ap’s-ar-ports(rm))  A  clearance(ap’S-ar-ports(rm))  <  clearance(ap) 

l3bel(do)  <  clearance(ap) 

Universal  instantiation  (5) 

12.  label(do)  <  clearance(ap’s-ar_ports(rm))  -4  label(do)  <  clearance(ap) 

Tautological  consequence  (10,11) 

13.  Flows(do,  rm,ap)  -4  label(do)  <  clearar)ce(ap)  Tautological  consequence  (8,12) 

14.  (Vd  :  Labeled.Data)[F[ows(d,rm,ap) label(d)  <  clearance(ap)] 

Universal  generalization  (13) 


Figure  6.2:  Formal  Proof  that  Dataflow  from  rm  to  ap  Satisfies  the  Security 
Policy 

the  Application  and  Resource  Managers,  the  Application  and  the  Transaction 
Manager,  and  the  Resource  Managers  and  the  Transaction  Manager.  A  secure 
channel  is  a  connector  that  enforces  the  security  policy.  In  other  words,  secure 
channels  will  not  carry  classified  data  from  a  component  to  a  component  that 
lacks  required  clearances.  To  say  that  the  system  as  a  whole  satisfies  the  security 
policy  means  that  there  is  no  flow  of  classified  data  to  a  component  that  lacks 
the  required  clearances.  The  security  of  the  system  follows  almost  immediately 
from  the  fact  that  it  employs  only  secure  channels,  making  a  textbook-style  nat¬ 
ural  deduction  proof  [18,  20]  of  system  security  quite  simple.  Consider  dataflow 
from  some  Resource  Manager  rm  to  the  Application  ap,  for  example.  A  proof 
of  the  formula 

(Vd  :  LabeIed-Data)[Flows(d,rm,ap) 

label(d)  <  clearance(ap)] 

which  says 

every  labeled  datum  d  that  flows  from  rm  to  ap  has  a  security  label 
classifying  it  that  is  less  than  or  equal  to  the  clearance  level  of  ap 

from  five  axioms  of  the  architectural  theory  is  shown  in  Figure  6.2. 

The  five  axioms  say 
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1.  every  labeled  datum  d  that  flows  from  rm  to  ap  is  carried  by  secure_ar_channel 
from  the  output  port  rm’s^ar_port  to  the  input  port  of  the  port  array 
ap's_ar_ports  that  is  indexed  by  rm, 

2.  the  input  port  of  the  port  array  ap’s_ar_ports  that  is  indexed  by  rm  is  a 
port  of  ap, 

3.  if  secure  channel  c  carries  labeled  datum  d  from  output  port  x  to  input 
port  y,  then  d’s  security  label  is  less  than  or  equal  to  the  clearance  level 
of  y, 

4.  the  clearance  level  of  any  port  y  of  component  a  must  be  less  than  or  equal 
to  the  clearance  level  of  a,  and 

5.  the  ordering  of  security  labels  is  transitive. 

The  first  two  ajcioms  are  facts  about  the  particular  architecture,  the  third  axiom 
is  the  defining  property  of  the  secure  channel  subtype,  the  fourth  and  fifth 
axioms  are  general  axioms  of  the  security  model. 

The  secure  channels  of  abstract  SDTP  architecture  can  be  implemented  in 
terms  of  ordinary  dataflow  channels  and  additional  components  in  a  variety 
of  ways,  depending  upon  the  security  properties  of  the  components  [27].  The 
most  interesting  implementation  is  shown  in  Figure  6.3.  This  implementation 
is  suited  to  the  case  where  all  of  the  resource  managers  and  the  application  are 
single-level,  but  not  necessarily  the  same  level.  The  security  policy  is  enforced 
by  a  multilevel  secure  component  that  filters  dataflow  between  the  application 
and  the  resource  managers:  if  passing  a  datum  from  a  resource  manager  to 
the  application  would  violate  the  security  policy,  the  filter  removes  it  from  the 
stream. 

A  proof  that  this  architecture  implements  the  more  abstract  architecture  is 
not  difficult  (cf.  [27]).  Intuitively,  it  amounts  to  showing  that  the  combination  of 
a  channel,  a  multilevel  secure  (MLS)  filter,  and  a  channel  is  a  correct  implemen¬ 
tation  of  a  secure  channel.  Ideally,  the  system  architect  should  not  be  burdened 
with  attempting  to  produce  such  proofs.  The  usual  way  of  avoiding  the  ne¬ 
cessity  of  proving  correctness  in  this  particular  case  is  to  prove  that  the  Filter 
Introduction  Transformation  (FIT)  * —  which  can  be  informally  represented  as 

{secure  channel)  — >  (channel)  +  (filter)  4-  (channel) 

where  +  indicates  connection  of  a  connector  to  a  component  —  always  produces 
correct  implementations.  But,  if  FIT  has  not  been  generally  verified,  how  can 
the  architect  who  is  convinced  of  its  correctness,  at  least  in  the  particular  case, 
proceed? 

If  the  architect  is  using  a  transformation  system  that  produces  “proof¬ 
carrying  architectures”,  when  transformation  FIT  is  applied,  it  is  applied  not 
only  to  the  architectural  description,  but  to  the  formal  security  proof  of  Fig¬ 
ure  6.2  as  well.  The  result  of  applying  FIT  to  this  proof  is  shown  in  Figure  6.4, 
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Figure  6.3:  More  Concrete  SDTP  Architecture  —  secure  channels  refined  to 
ordinary  channels,  or  ordinary  channels  plus  security  filter 

where  the  implementation  mapping  ^  associated  with  this  application  is  deter¬ 
mined  as  follows.  The  Carries  predicate 

Carries((5ecure  channel),  (datum),  (out  port),  (in  port)) 


that  is  mentioned  in  formulas  1,  3,  6,  and  7  of  the  abstract-level  proof  is  mapped 
to  a  conjunction  of  the  Carries,  Passes,  and  Carries  predicates, 

Carr\es{(channel),  (datum),  (out  port),  (filter  in  port)) 

A  Passes((ii/ter).  (datum),  (filter  in  port),  (filter  out  port)) 

A  Carries((c/ianneO.  (datum),  (filter  out  port),  (in  port)) 

This  clause  in  the  definition  of  y  says  that  a  secure  channel  carrying  a  datum 
from  some  output  port  to  some  input  port  is  implemented  as  a  channel  carrying 
the  datum  from  the  output  port  to  some  input  port  of  a  filter,  passing  the 
datum  through  the  filter  from  the  input  port  to  some  output  port,  and  carrying 
the  datum  from  the  output  port  of  the  filter  to  the  input  port.  This  mapping 
would  not  be  appropriate  to  apply  to  every  occurrence  of  the  Carries  predicate  in 
every  derivation,  because  not  every  secure  channel  in  the  abstract  architecture 
is  being  replaced  by  a  combination  of  two  channels  and  a  filter  in  the  concrete 
architecture.  However,  formulas  1,  6,  and  7  of  the  proof  specifically  refer  to 
what  secure.ar-channel  carries,  and  this  secure  channel  is  being  implemented  by 
two  channels  and  a  filter.  This  mapping  is  also  applied  to  formula  3  in  order 
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{1} 

1 

{2} 

2 

{3} 

3 

{4} 

4. 

{5} 

5, 

{1} 

6 

{3} 

7, 

{1.3} 

8 

{4} 

9 

{2,4} 

10 

{5} 

11, 

{2.4,5} 

12 

{1,2, 3, 4, 5} 

13 

{1, 2,3.4, 5} 

14 

{Vd  :  Labeled.Data)[Flows(d,  rm,  ap) 

— >  Carnes(rm_to_filter.channel,  d,  rm's_ar_port,  filterJn,port(rm))] 

A  Passes(mls-filter,  d,  filterjn.port(rm),  filter_out_port{rm))] 

A  Carries(fi!ter.to_ap^hannet(rm),  d,  filter.out.portfrm),  ap’s-ar_ports(rm))] 
Port.Of(ap’s-ar_ports{rm),  ap) 

{Vci  :  Channel){Vf  :  MLS-Component){Vc2  :  Channel)(Vd  :  Labeled-Data) 

(Vxj  :  Output-Port) (Vx2  :  Output.Port){Vyi  :  Input-Port) (Vy2  :  Input-Port) 
[Carries(ci,d,xi,yi)  A  Passesff,  d,  yi ,  X2)  A  Carries{C2 ,  d,  X2 ,  y2) 

— >  label(d)  <  clearance(y2)] 

(Va  :  Component) (Vy  :  lnput-Port)[Port-Of(y,  a)  — >  clearance(y)  <  clear3nce{a)] 
{Vsi,S2,S3  ;  Security-Lab€l)[si  <  S2  A  S2  <  S3  ^  Si  <  S3] 

Flows(do,  rm,  ap) 

—¥  Carries(rm-tO-filter>channel,  do ,  rm's-ar-port,  filterJn-port(rm)) 

A  Passes(mls.fi}ter,  do,  filterJn.port{rm),  filter-out-port(rm)) 

A  Carries(filter-tO-apjchanneI(rm),  do,  filter-out-port(rm),  ap‘s-ar-ports(rm)) 
Carries(rm-tO-filter-channet,  d,  rm's-ar-port,  filter-ln-port(rm) 

A  Passes(mls-filter,  do,  filter-in.port(rm),  filter-out-port(rm)) 

A  Carries(filter.to-ap-channel(rm),  do,filter-out-port(rm),  ap's-ar-ports(rm)) 

->  label(do)  <  clearance(ap’s-ar-ports(rm)) 
Flows(do,  rm,  ap)  — ^  label(do)  <  clearance(ap’s-ar-ports(rm)) 

Port-Of(ap’s-ar_ports(rm),  ap)  — >  clearance(ap’s_ar-ports(rm))  <  clearance{ap) 
clearance(ap's-ar_ports{rm))  <  clearance(ap) 

label(do)  <  clearance(ap's-ar-ports(rm))  A  ciearance(ap’s-ar-ports(rm))  <  clearance(ap) 

label(do)  <  clearance{ap) 

label(do)  <  clearance(ap’s-ar-ports(rm))  label(do)  <  clearance(ap) 

Flows(do,  rm,  ap)  — ►  label(do)  <  clearance(ap) 

(Vd  :  Labeled-Data)[Flows(d,  rm,  ap)  *-4  label(d)  <  clearanc€(ap)] 


Figure  6.4:  Transformed  Formal  Proof  that  Dataflow  from  rm  to  ap  Satisfies  the 
Security  Policy 


to  preserve  the  fact  that  formula  7  should  follow  from  formula  3  by  Universal 
Instantiation.  The  universal  quantifier  over  secure  channels  in  formula  3, 


(V  {secure  channel  variable)  :  Secure.Channel) 


is  mapped  by  c/to  universal  quantifiers  over  channels  and  a  universal  quantifier 
over  MLS  components, 

(V  {tO’filter  channel  variable)  :  Channel) 

(V  {filter  variable)  :  MLSXomponent) 

(V  {from-filter  channel  variable)  :  Channel) 

It  is  easy  to  check  that  the  result  of  applying  the  FIT  interpretation  map¬ 
ping  J^to  the  proof  of  security  is  a  syntactically  correct  derivation  of  the  desired 
security  property  from  formulas  that  are  images  of  a.xioms  of  the  more  abstract 
architectural  theory.  Mapping  sends  tautological  consequence  steps  to  correct 
tautological  consequence  steps,  universal  instantiation  steps  to  correct  universal 
instantiation  steps,  and  universal  generalization  steps  to  correct  universal  gen¬ 
eralization  steps.  So  y  has  indeed  mapped  the  formal  abstract-level  security 
proof  to  a  concrete-level  security  proof,  but  not  necessarily  a  proof  from  axioms 
of  the  concrete  architectural  theory. 
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{1}  1. 

{2}  2. 

{3}  3. 

{1}  4. 

{2}  5. 

{1,2}  6. 

{3}  7. 

{1,2,3}  8. 

{1,2,3}  9. 


(Vc  :  Channe!)(Vd  :  Labeled-Data)(Vx  :  Output-Port) (Vy  :  Input-Port) 

[Carries(c,d,x,y)  -4  dearance(x)  =  clearance(y)] 

Axiom  specifying  connection  constraint  imposed  by  security  model 
(Vf :  MLS_Component)(Vd  :  Labeled-Data) (Vy  :  Input-Port) (Vx  :  Output-Port) 

[Passes(f,d,y,x)  -y  label{d)  <  cle3rance{x)] 

Axiom  characterizing  MLS  components 
(Vx)(Vy)(Vz)[x  =  y  [z  <  x  44  z  <  y]]  Instance  of  identity  axiom  schema 

Carries(c2,do,X2,y2)  clearance(x2)  =  clearance(y2)  Universal  instantiation  (1) 

Passes(fo,do,yi,x2)  -4  label(do)  <  clearance(x2)  Universal  instantiation  (2) 

Carnes{ci ,  do ,  xi ,  yi )  A  Passes(fo ,  do ,  y i ,  X2 )  A  Carries(c2 ,  do ,  X2 ,  y2 ) 

-4  label(do)  <  clearance(x2)  A  clearance{x2)  =  clearance(y2) 

Tautological  consequence  (3,4) 

clearance{x2)  =  clearance(y2)  [label(do)  ^  clearance(x2)  44  label(do)  ^  clearance(y2) 

Universal  instantiation  (3) 

Carries(ci ,  do ,  xi ,  yi )  A  Passes(fo ,  do ,  y i ,  X2 )  A  Carries(C2 ,  do ,  X2 ,  y2 ) 

iabel(do)  <  clearance(y2) 
Tautological  consequence  (6,7) 

(Vci  :  Channe[)(Vf  :  MLS-Component)(Vc2  :  Channel)(Vd  :  Labeled-Data) 

(Vxi  :  Output-Port) (VX2  :  Output-Port) (Vyi  :  lnput.Port)(Vy2  :  Input-Port) 
[Carries(ci,d,xi,yi)  A  Passes(f, d, yi, X2)  A  Carries(c2, d, X2, y2) 

label(d)  <  clearance(y2)] 

Universal  generalization  (8) 


Figure  6.5:  Proof  of  Image  of  Abstract-Level  Formula  3  under  J^^from  Axioms 
of  Concrete  Theory 


The  image  of  the  first  axiom  under  says  that  every  labeled  datum  that 
flows  from  rm  to  ap  is  carried  to  the  Alter  from  rm,  passed  through  the  filter, 
and  then  carried  to  ap  from  the  filter.  Just  as  in  the  case  of  the  first  axiom,  this 
is  a  fact  about  the  particular  architecture  that  is  either  an  axiom  of  the  concrete 
theory,  or  easily  and  automatically  derivable  from  axioms  of  the  concrete  theory. 
The  mapping  ^  leaves  the  second  axiom  unchanged.  This  will  certainly  be  an 
axiom  of  the  concrete  theory,  as  well  as  the  abstract  theory.  The  image  of 
the  third  axiom  is  a  bit  more  complex.  It  states  that  the  combination  of  the 
two  channels  and  the  filter  enforces  the  security  property.  It  is  quite  unlikely 
that  this  would  be  among  the  chosen  axioms  of  the  concrete-level  theory,  since 
it  is  the  filter  alone,  effectively,  that  is  enforcing  security.  Still,  it  is  easy  to 
see  that  this  formula  must  be  a  consequence  of  axioms  of  the  concrete  theory: 
the  security  model  requires  that  channels  which  do  not  enforce  security  can 
only  connect  ports  with  matching  clearances,  and  one  of  the  defining  properties 
of  an  MLS  component  is  that  it  supplies  data  at  an  output  port  only  if  the 
classification  of  the  data  is  less  than  or  equal  to  the  clearance  of  the  port.  A 
formalization  of  this  proof  is  shown  in  Figure  6.5.  Discovery  of  this  proof  is  easy. 
The  form  of  the  desired  conclusion  —  a  conjunction  of  conditions  on  Carries 
and  Passes  in  the  antecedent,  and  the  comparison  of  label  to  clearance  in  the 
consequent  —  immediately  suggests  the  use  of  the  axioms  on  lines  1  and  2  of  the 
proof.  So  it  should  be  quite  plausible  that  the  proof  can  be  discovered  without 
human  intervention  by  the  transformation  system.  The  interpretation  mapping 
y  does  not  affect  the  images  of  the  remaining  two  axioms;  they  remain  general 
axioms  of  the  security  model.  So,  by  combining  the  proof  in  Figure  6.5  with 
the  proof  in  Figure  6.4,  we  obtain  a  proof  of  the  security  property  from  axioms 
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of  the  concrete  theory.  Moreover,  this  proof  is  recognizably  a  formalization  of 
our  informal  argument  [27,  p.  89]  that  the  concrete  architecture  satisfies  the 
security  policy. 


6.4  Generalizing  from  the  Example 

The  idea  of  using  the  architectural  transformation  to  transform  the  proof  that 
the  more  abstract  architecture  has  a  desired  property  into  a  proof  that  the 
more  concrete  architecture  has  the  property  worked  well  for  this  rather  simple 
example.  Is  there  any  reason  to  believe  that  it  will  work  equally  well  in  other 
cases? 

Recall  that  the  standard  criterion  for  correctness  of  an  implementation  map¬ 
ping  J  of  an  abstract  logical  theory  Q  (of  first-order  logic)  in  a  more  concrete 
(first-order)  theory  &  is  that  must  interpret  0  in  0',  i.e.,  it  must  be  the  case 
that,  for  every  formula  ^  in  the  language  of  0, 

0  1=  0'  c/((^) 

The  basic  facts  about  theory  interpretation  can  be  found  in  the  logic  text¬ 
books  of  Enderton  [8]  and  Shoenfield  [44],  among  others.  For  present  purposes, 
it  is  enough  to  know  that 

1.  for  every  formula  ^  of  the  language  of  the  more  abstract  theory, 

and  similarly  for  the  other  connectors,  and 

2.  for  every  formula  ^  of  the  language  of  the  more  abstract  theory,  and  every 
variable  x, 


c/(Vx  v?)  =  Vx  [ujjr(x)  y{(p)  ] 

where  ujy{x)  is  some  formula  determined  by  c/,  not  dependent  upon  c/?,  in 
which  only  x  occurs  freely,  and  similarly  for  the  other  quantifiers. 

If  y  interprets  0  in  0',  an  easy  inductive  argument  shows  that  maps 
formal  proofs  from  0  to  formal  proofs  from  ./[0]  that  can  be  extended  to  proofs 
from  &.  If  (/?  is  an  axiom  of  0,  then,  since  J^is  a  theory  interpretation, 
is  derivable  from  0'.  Because  c/  is  defined  so  that  connectives  pass  through 
it,  y  maps  tautological  consequence  steps  to  tautological  consequence  steps. 
Because  uniformly  restricts  quantifiers,  ^  maps  universal  instantiation  and 
universal  generalization  steps  to  universal  instantiation  and  generalization  steps, 
respectively.  Thus,  ./maps  formal  proofs  from  abstract  axioms  to  formal  proofs 
from  images  of  abstract  axioms,  and  images  of  abstract  axioms  can  always  be 
proved  from  concrete  axioms. 

So,  if  an  architectural  transformation  step  is  correct,  in  the  standard  sense, 
the  corresponding  interpretation  mapping  will  map  formal  proofs  to  formal 
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proofs  containing  small  gaps.  A  fortiori,  an  abstract-level  formal  proof  of  some 
particular  property  of  interest  —  say,  satisfaction  of  a  security  policy  will  be 
mapped  to  a  proof  that  the  implementation  also  has  (the  implementation-level 
analogue  of)  the  property.  Since  the  replacement  of  the  secure  channel  from  rm 
to  ap  by  a  pair  of  channels  and  a  filter  is  evidently  correct,  it  is  not  surprising 
that  the  FIT  mapping  sends  the  abstract-level  security  proof  to  a  concrete-level 
security  proof. 

It  follows  that  the  proof-carrying  architecture  approach  allows  the  architect 
to  perform  arbitrary  correct  transformations  when  implementing  an  abstract 
architecture,  provided  the  transformation  system  that  supports  the  approach 
is  clever  enough  to  find  the  proofs  of  images  of  axioms.  Of  course,  incorrect 
transformations  that  happen  to  preserve  the  proof  of  the  property  of  interest  are 
also  allowed.  Therefore,  this  approach  is  well-suited  to  the  case  where  the  focus 
is  on  obtaining  an  implementation  with  some  particular  desirable  property 
i.e.,  when  a  weaker- than-usual  correctness  criterion  is  adequate  —  and  placing 
minimal  constraints  on  the  architect’s  implementation  options  is  preferred. 


6.5  Related  Work 

Although  there  is  a  large  and  growing  literature  on  formal  software  transfor¬ 
mation,  nearly  all  of  it  is  oriented  toward  maintaining  functional  correctness, 
rather  than  system  structure.  Similarly,  there  is  a  large  body  of  literature  on 
architectural  refinement  and  composition,  nearly  all  of  it  employing  semifor- 
mal  representation  and  analysis  techniques,  at  best.  The  comparatively  few 
papers  on  formal  refinement  of  architectural  structure  include  Broy’s  work  on 
component  refinement  [4],  Brinksma,  et  al.’s,  work  on  connector  refinement  [3], 
Philipps  and  Rumpe’s  recent  work  on  refinement  of  information  flow  architec¬ 
tures  [35],  and  the  work  described  in  our  own  earlier  papers  [25,  26,  27,  39,  41]. 
Also  closely  related  is  work  by  Garlan’s  group  [1],  Luckham’s  group  [19],  and 
Moriconi  and  Qian  [25]  on  formally  representing  the  semantics  of  connectors  and 
relating  semantic  models  at  different  levels  of  abstraction.  But,  the  emphasis 
in  all  these  cases  has  always  been  on  verification  of  general  refinement  patterns, 
rather  than  checking  particular  steps. 

Necula  and  Lee’s  work  on  proof-carrying  code  and  its  applications  [31,  32,  30] 
introduced  the  notion  of  replacing  verification  by  checking  in  the  context  of  com¬ 
pilation.  The  work  described  in  this  paper  can  be  viewed  as  generalizing  their 
ideas  about  code  refinement  transformations  to  architectural  transformations, 
both  refinements  and  abstractions. 

6.6  Chapter  Summary 

Transformational  development  of  architectures  can  guarantee  that  implementa¬ 
tions  are  correct  by  restricting  the  zu'chitect  to  a  stock  of  verified  transforma¬ 
tions.  But  such  a  correctness  guarantee  is  quite  brittle,  since  use  of  a  single 
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non-verified  transformation  voids  the  guarantee.  Moreover,  confidence  that  the 
implementation  is  correct  should  be  no  greater  than  confidence  that  all  the  ver¬ 
ifications  are  correct.  If  many  transformations  are  used,  and  the  verification  of 
each  is  difficult,  then  confidence  in  the  correctness  of  the  implementation  may 
be  less  than  desired,  especially  in  safety-critical  applications.  Checking  particu¬ 
lar  refinement  steps  offers  a  way  of  allowing  the  architect  greater  freedom,  and 
of  achieving  higher  levels  of  confidence  that  the  implemented  architecture  has 
the  desired  properties. 

Our  initial  approach  to  checking,  based  on  the  idea  of  proof-carrying  archi¬ 
tectures,  is  especially  well  suited  to  the  case  where  the  main  requirement  is  high 
confidence  that  the  implementation  has  some  specific  property.  The  property 
is  shown  to  hold  at  some  abstract  level,  and  every  refinement  is  produced  by 
application  of  a  transformation  known  to  preserve  the  property,  or  is  checked 
for  correctness  by  making  sure  that  the  transformation  preserves  the  proof  of 
the  desired  property,  or  both. 

The  main  limitation  of  this  first  approach  to  checking  is  that  only  a  lim¬ 
ited  range  of  properties  can  be  checked.  The  approach  is  too  weak  to  ensure 
that  an  implementation  step  is  correct,  in  the  standard  sense,  which  requires 
preservation  of  a  broad  range  of  properties.  For  that  reason,  we  are  exploring 
other  approaches  to  checking  in  parallel  with  the  proof-carrying  architectures 
research.  An  alternative  approach  that  seems  particularly  promising  is  based  on 
the  idea  of  applying  the  simplified  technique  for  proving  implementation  map¬ 
ping  correctness  [39]  at  architecture-definition-time  to  particular  development 
steps.  This  approach  will,  in  certain  circumstances,  allow  checking  that  partic¬ 
ular  steps  are  correct,  according  to  our  strong  correctness  criterion,  rather  than 
checking  one  or  a  few'  properties  of  interest. 

Proof-carrying  architectures  are  being  implemented  as  part  of  the  Xform^ 
system.  Xform,  pronounced  transform,  is  a  recursive  acronym  for  ''Xform,  for 
orderly  reification^  and  maintenance. ''  Xform  is  a  toolset  for  transformational 
development  and  maintenance  of  architectural  descriptions  written  in  languages 
such  as  Sadl  [28]  and  Acme  [11]. 


^  Xform  is  a  common  mathematical  shorthand  for  transform. 

^To  reify  means  to  make  actual.  Thus,  reification  of  software  architectures  is  the  process 
of  turning  them  into  actual  implementations. 
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Chapter  7 


Overview  of  the  SDTP 
Derivation 

7-1  Introduction 

The  primary  focus  of  our  research  efforts  is  on  the  problem  of  producing  de¬ 
pendable  system  architectures.  We  have  recently  developed  the  basic  technology 
required  to  effectively  solve  this  problem  in  the  case  of  distributed  transaction 
processing  systems.  Our  solution  involves  extending  the  ACID  properties  that 
drove  the  development  of  the  X/Open  standard  for  distributed  transaction  pro¬ 
cessing  by  adding  security  constraints.  Specifically,  we  added  the  constraint 
that  the  system  must  satisfy  a  multilevel  secure  access  control  policy.  Our 
basic  approach  to  defining  a  family  of  architectures  that  satisfy  the  extended 
requirements  was  described  in  an  earlier  paper  [27].  This  chapter  is  devoted  to 
describing  our  experiences  in  following  that  approach  to  its  logical  conclusion: 
an  implemented  architecture  for  secure  distributed  transaction  processing  that 
has  been  proven  secure. 


7.2  Architecture  Hierarchies 

It  is  common  practice  to  informally  describe  a  single  architecture  at  many  levels 
of  abstraction,  and  from  a  variety  of  different  perspectives.  For  example,  at  a 
concrete  level,  the  architecture  might  be  described  in  terms  of  how  a  system  is 
assembled  from  code  components  using  connection  mechanisms  provided  by  a 
programming  language  or  operating  system.  At  a  very  abstract  level,  the  same 
architecture  might  be  described  in  terms  of  the  data  and  control  flow  paths 
that  link  the  functions  the  system  is  required  to  perform.  At  an  intermediate 
level,  the  system  architecture  might  be  described  in  terms  of  clients  and  servers 
interacting  through  message  queues. 

One  reason  that  multiple  descriptions  are  provided  is  that  each  of  these  archi- 
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—  abstract  architectural  description 

—  alternative  verified  refinements 

—  alternative  slightly  more  concrete 
architectural  descriptions 

—  additional  refinements 

—  yet  more  concrete  descriptions 


V' 


11 


O  O 


V' 


O 


^  —  implementation-level  descriptions, 
O  linked  to  abstract  description  by 
chain  of  verified  refinements 


Figure  7.1:  An  Architecture  Hierarchy 


tectural  descriptions  is  useful  for  some  purposes,  but  less  useful  for  others.  Often 
the  argument  that  the  system  has  some  desirable  architectural  property  can  be 
greatly  simplified  by  employing  an  abstract  description  of  the  architecture.  On 
the  other  hand,  some  properties  require  detailed  analysis  of  low-level  architec¬ 
tural  descriptions.  Another  reason  is  that  there  is  often  a  major  conceptual 
gap  between  abstract  architectural  descriptions  and  the  actual  implementation. 
Descriptions  at  intermediate  levels  of  abstraction  break  this  gap  down  into  intel¬ 
lectually  tractable  pieces,  and  thus  can  significantly  increase  confidence  that  the 
abstract  description  correctly  characterizes  the  as-implemented  architecture. 

While  much  of  the  recent  work  on  more  formal  architectural  description  lan¬ 
guages  (ADLs)  has  focused  on  the  problem  of  describing  architectures  in  a  way 
that  provides  a  suitable  basis  for  various  formal  analyses,  our  own  work  has  fo¬ 
cused  primarily  on  the  problem  of  formally  linking  these  several  descriptions  in 
an  architecture  hierarchy.  The  basic  idea  is  to  regard  each  description  as  a  logi¬ 
cal  theory,  the  theory  of  the  class  of  architectural  structures  that  the  description 
describes,  and  to  formalize  the  links  between  the  descriptions  as  interpretation 
mappings.  Figure  7.1  shows  the  structure  of  a  typical  architecture  hierarchy. 
Correctness  of  the  hierarchy  can  be  explicated  in  terms  of  constraints  on  the  in¬ 
terpretation  mappings.  For  example,  one  might  require  that  the  interpretations 
preserve  some  property  of  special  interest  (say,  some  security  property).  Or  one 
might  require  that  they  preserve  every  property  expressible  in  some  language. 

Our  tools  for  constructing  architecture  hierarchies  are  based  upon  an  in¬ 
cremental  transformation  paradigm.  The  result  of  applying  a  transformation 
to  a  hierarchy  is  a  hierarchy  containing  additional  or  altered  descriptions.  An 
additional  description  is  typically  either  an  abstraction  of  another  description 
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Figure  7.2:  The  X/Open  DTP  Reference  Architecture 


in  the  hierarchy,  a  refinement  of  another  description  in  the  hierarchy,  or  a  de¬ 
scription  at  the  same  level  of  abstraction  but  from  a  different  perspective  (c.g., 
a  data-oriented  description  that  complements  an  existing  function-oriented  de¬ 
scription)  .  If  a  hierarchy  has  been  constructed  entirely  by  applications  of  trans¬ 
formations  that  are  known  to  be  generally  correctness-preserving,  or  whose  cor¬ 
rectness  in  the  particular  instance  is  checked  as  they  are  applied,  the  hierarchy 
is  known  to  be  correct.  Correct  hierarchies  formally  link  very  abstract  formal 
architectural  descriptions,  which  can  easily  be  demonstrated  to  satisfy  system 
requirements,  to  implementation-level  architectural  descriptions  in  a  way  guar¬ 
anteeing  that  the  implementation  satisfies  the  requirements. 


7.3  Distributed  Transaction  Processing 

In  response  to  a  growing  demand  for  increased  interoperability  of  software  com¬ 
ponents,  several  vendor-neutral,  open  software  architectures  have  been  proposed 
as  standards.  The  X/Open  Distributed  Itansaction  Processing  (DTP)  refer¬ 
ence  architecture  [46]  is  one  of  these  standards.  X/Open  DTP  is  specifically 
intended  to  standardize  interactions  among  the  components  of  a  three-tiered 
client/server  model;  resource  (e.g.,  database)  managers  (RMs),  an  application 
(AP)  that  accesses  those  resources,  and  a  transaction  manager  (TM).  A  very 
abstract,  informal  representation  of  this  architecture  which  can  be  found  in 
the  X/Open  documents  —  is  shown  in  Figure  7.2. 

The  role  of  the  TM  is  to  ensure  that  consistency  is  maintained  when  the  state 
of  the  RMs  is  changed  by  the  AP.  Transactions  are  collections  of  operations  on 
the  RMs.  Multiple  transactions  can  be  performed  concurrently.  In  the  context 
of  a  transaction,  all  other  transactions  appear  to  be  executed  atomically.  In 
other  words,  it  always  appears  that  all  or  none  of  the  operations  that  make  up 
a  transaction  have  taken  effect. 

The  X/Open  documentation  is  informal,  consisting  of  a  mix  of  C  header 
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files^  and  English  text  describing  the  semantics  of  the  functions  declared  in 
the  headers.  The  protocols  for  using  these  functions  are  also  only  semiformally 
characterized. 


7.4  Adding  Security  to  DTP 

Security  requirements  are  ubiquitous  in  transaction  processing,  both  within  the 
defense  sector  and  within  the  commercial  sector.  Tremendous  leverage  can  be 
gained  by  addressing  security  concerns  at  the  architectural  level,  because  ensur¬ 
ing  security  is  typically  both  technically  challenging  and  expensive.  Several  of 
the  open  software  architectures  have  introduced  extensions  to  deal  with  secu¬ 
rity  issues.  For  example,  recent  updates  of  OMG’s  CORE  A  specification  have 
included  security  services  that  address  fundamental  security  concerns  in  a  dis¬ 
tributed  object  system,  based  on  a  trusted  ORB  model.  These  services  include 
credential-based  authentication  of  principals  and  their  clients,  several  simple 
privilege  delegation  schemes,  authorization  based  on  access  control  lists,  audit 
trails,  and  non-repudiation  services  based  on  the  ISO  non-repudiation  model. 

One  of  the  key  security  issues  in  DTP  is  enforcement  of  an  access  control 
policy,  which  ensures  that  classified  resoures  can  be  accessed  only  by  clients  with 
appropriate  clearances.  In  terms  of  the  Bell-LaPadula  model  [17],  our  proposed 
multilevel  secure  (MLS)  access  control  policy  for  secure  DTP  can  be  defined 
by  saying  that  the  distributed  transaction  processing  systems  must  have  the 
following  two  properties: 

•  The  Simple  Security  Property  —  A  client  is  allowed  read  access  to  a  re¬ 
source  only  if  the  client’s  clearance  level  is  greater  than  or  equal  to  the 
resource’s  classification  level. 

•  The  'k-Property  —  A  client  is  allowed  write  access  to  a  resource  only  if  the 
client’s  clearance  level  is  less  than  or  equal  to  the  resource’s  classification 
level. 

The  simple  security  property  guarantees  that  there  is  no  read-up  of  data,  while 
the  ★-property  guarantees  that  there  is  no  write-down. 

To  say  that  a  component  in  a  DTP  system  is  MLS  means  that  the  component 
satisfies  the  MLS  access  policy  internally,  and  that  all  inputs  to  and  outputs 
from  the  component  are  properly  classified.  So,  for  example,  to  say  that  a 
multilevel  database  management  system  (DBMS)  is  an  MLS  resource  manager 
means  that 

•  any  data  entered  into  the  database  is  tagged  with  a  classification  level, 

•  any  data  retrieved  from  the  database  comes  tagged  with  the  same  classi¬ 
fication  level  that  it  had  when  it  was  entered,  and 

^  Since  a  description  of  how  components  written  in  languages  other  than  C,  including  lan¬ 
guages  such  as  COBOL  that  do  not  support  return  values,  can  be  accommodated  is  included, 
it  is  clear  that  the  C  code  cannot  be  considered  to  be  a  formal  specification  of  the  syntax  of 
the  interface  functions. 
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•  no  operation  performed  by  the  DBMS  can  result  in  either  read-up  or 
write-down  among  the  subcomponents  of  the  DBMS. 

(Note  that  a  single-level  database  is  trivially  an  MLS  resource  manager,  provided 
single-levelness  is  maintained.)  Similarly,  to  say  that  the  entire  DTP  system  is 
MLS  means  that  no  read-up  or  write-down  occurs  between  components  and  that 
inputs  and  outputs  are  properly  classified. 

The  challenge  in  adding  an  MLS  access  control  policy  to  X/Open  DTP  is  to 
define  an  architecture  which  guarantees  that,  if  the  components  used  to  build 
the  system  are  MLS,  then  the  DTP  system  as  a  whole  is  MLS.  That  this  is 
not  a  trivial  problem  can  be  seen  by  considering  a  DTP  system  coniposed  of 
an  application  that  accesses  several  single-level  databases,  each  of  which  has  a 
different  classification  level,  a  very  common  situation.  A  secure  DTP  (SDTP) 
architecture  must  ensure  that  the  client  application  does  not  read  data  classi¬ 
fied  above  the  application’s  clearance  level,  that  it  does  not  write  data  that  it 
obtained  from  a  highly  classified  database  to  a  database  classified  at  a  lower 
level,  and  so  on. 

One  complicating  factor  is  that  no  single  architectural  structure  is  well  suited 
to  every  SDTP  system.  It  is  easy  to  see  that  a  single-level  client  AP,  a  single-level 
TM,  and  a  collection  of  single-level  RMs  all  at  the  same  level  can  be  linked  by 
secure  connectors  to  build  a  system  that  is  automatically  MLS  secure.  Extend¬ 
ing  the  X/Open  DTP  architecture  to  handle  such  systems  can  be  accomplished 
simply  by  adding  appropriate  encryption  to  the  communication  protocols.  But 
varying  single-level  systems  will  reQuire  that  the  connectors  linking  the  AP  to 
the  RMs  somehow  enforce  the  access  control  policy  (at  least  in  the  absence  of  a 
certification  that  the  AP  satisfies  security  constraints  beyond  being  MLS).  One 
way  of  doing  so  is  to  introduce  a  Security  Manager  component  that  mediates 
communication  between  the  RMs  and  the  MLS  AP,  as  shown  in  Figure  7.3. 

7.5  Defining  the  SDTP  Hierarchy 

As  part  of  an  earlier  eflfort  to  develop  an  architectural  description  language 
suitable  for  defining  architectural  hierarchies,  we  defined  a  formal  hierarchy  for 
the  X/Open  DTP  standard  consisting  of  17  Sadl  [28]^  specifications,  linked  by 
SADL-specified  interpretation  mappings.  The  most  abstract  description,  shown 
in  Figure  7.4,  approximately  corresponds  to  the  informal  diagram  shown  in 
Figure  7.2.  Six  levels  below  the  most  abstract  description  is  a  description  at 
roughly  the  same  level  of  abstraction  as  the  code  in  the  X/Open  documenta¬ 
tion.  (Excerpts  from  this  code  are  shown  in  Figure  7.5.)  Below  this  level,  the 
hierarchy  branches  in  several  directions,  reflecting,  e.g.,  the  various  choices  that 
can  be  made  in  allocating  low-level  interprocessor  communication  functions  to 
processors. 

2  Sadl,  pronounced  saddle,  is  an  acronym  for  ‘Structural  Architecture  Description  Lan¬ 
guage’.  The  name  was  suggested  by  the  fact  that  Sadl  emphasizes  description  of  structure 
rather  than  description  of  the  behavior  of  connectors,  a  topic  quite  adequately  addressed  by 
other  ADLs. 
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Figure  7.3:  SDTP  Architecture  for  Varying  Single-level  Resource  Managers 


x_open_abstract :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  Dataf lowJlelations^tyle 
BEGIN 

CONFIGURATION 

ap:  TYPE  <=  Function 
rms:  TYPE  <=  Function 
tm:  TYPE  <=  Function 

the_ap:  ap 
the_rins :  rms 
the.tm:  tm 

ar:  CONSTRAINT  =  Dataf low(the^p,  the^rms) 
tx:  CONSTRAINT  =  Dataflow  (the  jap,  the.tm) 
xa:  CONSTRAINT  =  Dataf low(the_tm,  the_rms) 

END  x_open_abstract 

Figure  7,4:  Dataflow-Level  Sadl  Description  of  X/Open  Architecture 
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X-opemstd-level :  ARCHITECTURE  [  “>  3 
•/,%  X^Open^style  defines  relevant 
*/,*/,  properties  of  procedure  calls; 
y.y,  this  description  covers  how  things 
y.y,  are  hooked  together 

IMPORTING  ALL  FROM  X_Open-Style  ,  .  .  . 

BEGIN 

COMPONENTS 

tm:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register :  AX_Register-Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret :  INT] 

begin:  TX_Begin-Proc  [  ->  ret:  INT] 
END  tm 
the-tm:  tm 


CONFIGURATION 

tx:  CONSTRAINT  = 

Called-From(the-tm. begin,  the_ap) 

AND  ... 

xa:  CONSTRAINT  = 

(FORALL  y:  rm) 

[Called_From(the_tm. register,  y) 

AND  ... 

END  x_open_std_level 

Figure  7.5:  X/Open  Standard-Level  Sadl  Description  of  X/Open  Architecture 
(Heavily  Elided) 
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Our  basic  approach  to  developing  a  similar  hierarchy  for  SDTP  architec¬ 
tures  was  to  treat  SDTP  as  a  rearchitecting  problem:  given  an  architecture 
that  satisfies  a  set  of  requirements,  how  can  that  architecture  be  modified  to 
satisfy  an  additional  requirement,  viz.,  that  the  MLS  access  policy  is  satisfied. 
The  idea  is  to  attempt  to  “replay”  the  derivation  of  the  implementation-level 
architecture  descriptions  from  the  most  abstract  architectural  description.  An 
architecture  hierarchy  includes  a  record  of  the  transformations  used  to  generate 
the  interpretations  that  link  the  descriptions.  If  a  transformation  used  in  the 
original  X/Open  DTP  hierarchy  can  be  shown  to  preserve  satisfaction  of  the 
additional  requirement  —  i.e.,  in  this  catse,  if  the  transformation  can  be  shown 
to  preserve  the  simple  security  property  (no  read-up)  and  the  ★-property  (no 
write-down)  —  then  the  same  transformation  can  be  employed  in  deriving  an 
SDTP  implementation.^ 

A  priori,  it  was  not  known  what  percentage  of  the  design  history  encoded  in 
the  X/Open  DTP  hierarchy  could  be  reused  in  the  SDTP  hierarchy.  We  there¬ 
fore  developed  implementation-level  descriptions  of  the  three  abstract  architec¬ 
tures  for  SDTP  that  we  have  described  in  an  earlier  publication  [27].  It  turned 
out  that  over  90%  of  the  design  decisions  made  during  the  implementation  of 
each  of  the  three  SDTP  architectures  could  be  based  on  decisions  recorded  in 
the  DTP  hierarchy;  conversely,  every  design  decision  in  the  DTP  hierarchy  was 
reused  in  the  development  of  every  one  of  the  three  SDTP  hierarchies.  In  the 
most  extreme  case,  the  hierarchy  for  the  “single-level,  same-level  RMs”  case  is 
nearly  identical  to  the  DTP  hierarchy,  the  only  real  difference  being  an  addi¬ 
tional  low-level  decision  to  use  an  RPC  mechanism  that  performs  encryption. 
Thus,  one  important  result  of  this  case  study  w’as  evidence  that  confirms  our 
hypothesis  that  derivation  replay  is  often  an  effective  rearchitecting  technique. 


7.6  Verifying  Security 

We  believe  that  our  implementation-level  SDTP  architectural  descriptions  de¬ 
fine  architectures  that  have  the  simple  security  property  and  the  ★-property, 
because  we  have  formally  proved  that  these  properties  follow  from  a  dataflow- 
level  description  of  the  SDTP  architectures  in  terms  of  components  linked  by 
channels  that  enforce  security  and  we  are  in  the  process  of  formally  confirming 
our  belief  that  the  design  decisions  in  the  SDTP  hierarchies  preserve  security. 
The  proofs  that  the  design  decisions  preserve  the  desired  security  properties  use 
two  different  verification  techniques  we  have  developed. 

Many  of  the  transformations  employed  in  development  can  be  shown  to  pre¬ 
serve  a  broad  class  of  structural  properties  by  showing  that  the  implementation 
links  they  introduce  into  the  hierarchy  are  faithful  interpretations  of  the  theory 
of  the  more  abstract  description  in  the  theory  of  the  more  concrete  description. 

^The  bindings  of  the  variables  in  the  transformation  can,  and  usual  do,  change.  But  the 
bindings  in  the  replay  can  be  automatically  determined  from  the  bindings  in  the  original 
derivation  by  tracking  the  correspondence  between  objects  in  the  two  hierarchies  as  the  new 
hierarchy  is  constructed  from  the  old. 
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To  say  an  interpretation  J'  oi  the  language  of  theory  (9i  in  theory  02  Is  a  faithful 
(theory)  interpretation  means  that,  for  every  sentence  (i.e.,  closed  formula)  ^ 
in  the  language  of  0i , 

01  h  if  and  only  if  02  ^ 

In  general,  access  control  policies  prohibit  certain  dataflow  paths  in  the  system. 
Simply  by  omitting  the  undesired  dataflow  channels  from  the  abstract  architec¬ 
tural  description,  we  guarantee  that  no  formula  saying  there  is  a  dataflow  from 
Cl  to  02 )  where  a  flow  from  component  0i  to  component  02  would  violate  the 
access  control  policy,  can  be  proved  from  the  theory  of  the  abstract  descrip¬ 
tion.  Faithful  interpretations  cannot  introduce  new  dataflow  channels,  but  can 
only  further  elaborate  existing  channels.  Therefore,  transformations  that  can 
be  shown  to  always  introduce  faithful  interpretations  can  freely  be  used  in  the 
process  of  implementing  a  design  that  has  been  verified  to  be  secure,  without 
fear  that  security  will  be  violated.  The  details  of  our  model-theoretic  method  for 
proving  that  transformations  always  introduce  faithful  interpretation  links  have 
been  described  in  a  series  of  earlier  papers  [26,  39,  41].  Currently,  we  manually 
prove  that  transformations  introduce  faithful  theory  interpretations,  though  we 
are  actively  investigating  the  possibility  of  using  SRFs  PVS  verification  system 
to  provide  automated  support  for  the  process. 

On  the  other  hand,  not  every  interpretation  link  in  the  SDTP  hierarchies 
has  been  shown  to  be  a  faithful  theory  interpretation.  In  fact,  some  of  the 
transformations  employed  in  building  the  hierarchies  do  not  have  the  property 
that  they  always  introduce  faithful  interpretations.  For  these  interpretations, 
we  apply  a  checking  technique  to  show  that  the  interpretation  preserves  the 
desired  security  properties.  The  basic  idea  is  to  use  the  interpretations  that 
refine  the  architectural  description  to  refine  the  proof  that  the  descriptions  have 
the  desired  security  properties  as  well.  If  the  result  of  applying  the  interpretation 
to  the  security  proof  at  the  more  abstract  level  can  be  used  to  automatically 
obtain  a  security  proof  at  the  more  concrete  level,  the  implementation  step  has 
been  shown  to  preserve  security.  (This  technique  has  been  described  in  greater 
detail  in  an  earlier  paper  [40].)  Currently,  we  apply  the  transformations  to 
proofs  manually,  and  then  use  PVS  to  check  the  results.  A  tool  that  automates 
proof  transformation  is  under  development. 


7.7  Implementing  an  SDTP  Reference  Architec¬ 
ture 

In  this  SDTP  reference  implementation  the  RMs  consist  of  a  Security  Manager 
(SM)  that  enforces  the  desired  multilevel  security  policies  —  each  of  which 
implements  a  piece  of  the  Security  Manager  component  shown  in  Figure  7.3 
—  and  a  set  of  single-level  RMs,  which  are  arbitrary  single-level  databases.  A 
multilevel  secure  RM  consists  of  the  combination  of  the  SM  and  the  single-level 
RMs.  Note  that  the  single-level  RMs  are  not  required  to  provide  the  X/Open 
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DTP  standard  services  themselves;  they  must,  however,  support  transaction 
processing. 

The  X/Open  DTP  standard  specifies  various  services  that  the  components 
of  the  architecture  must  provide  and  make  use  of.  An  SDTP  application  will 
make  use  of  two  services:  the  TX  (Transaction  Demarcation)  service,  and  the 
AR  service  (the  service  that  allows  the  application  access  to  shared  resources). 
The  TX  service  is  provided  by  the  TM  while  the  AR  service  is  provided  by  the 
(multilevel)  RMs  the  application  makes  use  of. 

The  TM  and  RMs  also  make  use  of  X/Open  DTP-specified  services.  The 
service  the  RMs  provide  to  the  TM  is  called  the  xa  subservice  of  the  XA  service. 
This  subservice  implements  the  interface  the  TM  uses  to  perform  the  two-phase 
commit  protocol.  The  ax  subservice  of  the  XA  service  is  provided  by  the  TM 
and  allows  RMs  to  dynamically  register  themselves  as  being  under  the  TM’s 
management,  and  unregister  themselves  when  that  management  is  no  longer 
desired. 

The  X/Open  DTP  standard  gives  a  detailed  specification  of  the  TX  and 
XA  services.  The  AR  service  is  considered  implementation-dependent  because 
RMs  may  provide  services  other  than  database  management,  and  thus  the  AR 
interface  must  allow  its  clients  to  make  use  of  those  services. 

Our  reference  implementation  of  SDTP  was  written  in  Common  Lisp.  The 
advantage  of  using  a  language  quite  different  from  X/Open’s  choice  of  C  is  that 
it  helped  us  identify  and  eliminate  some  of  the  “C-centric”  implementation  de¬ 
cisions  that  crept  into  the  X/Open  design.  Common  Lisp  was  also  attractive 
because  it  enabled  rapid  implementation  and  debugging  of  the  system.  The 
Common  Lisp  package  system  was  used  to  globally  identify  the  various  services 
and  prevent  name  conflicts  (e.g.,  since  open  is  a  standard  Common  Lisp  func¬ 
tion  for  file  I/O  as  well  as  appearing  in  both  the  TX  and  XA-xa  service,  a 
name  conflict  would  occur  unless  some  method  of  distinguishing  between  these 
functions  was  employed). 

A  remote  procedure  call  (RPC)  facility  native  to  the  Common  Lisp  version 
we  used  was  employed  for  component-to-component  communication.  Commu¬ 
nication  between  the  RMs  and  the  single-level  databases  was  done  by  means  of 
a  foreign  function  interface  (FFI)  to  the  native  database  programmatic  interface 
library. 

7.7.1  The  TX  Service 

The  TX  service  allows  the  application  to  open  and  close  resource  managers, 
start,  finish  or  roll  back  transactions,  obtain  information  about  the  state  of  a 
transaction,  and  set  certain  transaction  characteristics, 

A  typical  chain  of  events  involving  the  application  making  use  of  the  TX 
service  is 

1.  Tell  the  TM  to  open  the  RMs  with  the  tx:open  call. 

2.  Connect  to  the  RMs  and  use  the  AR  services  of  the  RM  for  preliminary 
functions  (such  as  authentication  and  key  exchange). 
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3.  Tell  the  TM  to  start  a  transaction  with  the  tx:  begin  call. 

4.  Use  the  AR  service  of  the  RMs  to  exchange  data. 

5.  Finish  the  transaction  by  using  the  TM’s  tx:coimnit  call;  alternatively, 
abort  and  roll  back  the  transaction  using  the  tx :  rollback  call. 

6.  Once  the  desired  set  of  transactions  is  completed,  tell  the  TM  to  close  the 
RMs  by  using  the  tx :  close  call. 

7.7.2  The  XA  Service 

The  XA  service  is  used  by  the  TM  to  communicate  with  the  RMs  and  by 
the  RMs  to  communicate  with  the  TM.  It  is  divided  into  two  subservices  as 
described  above. 

The  xa  subservice  is  used  by  the  TM  to  communicate  with  the  RMs  to 
negotiate  the  two-phase  commit  protocol.  A  typical  chain  of  events  is 

1.  The  application  informs  the  TM  that  it  wishes  to  begin  processing  trans¬ 
actions  (via  the  ax  subservice,  described  below). 

2.  The  TM  uses  the  xatopen  call  to  tell  the  RMs  to  begin  listening  for 
connections  from  the  application. 

3.  The  application  tells  the  TM  that  it  is  beginning  a  transaction. 

4.  The  TM  issues  xa:  start  calls  to  the  RMs,  telling  them  that  a  new  trans¬ 
action  is  being  started. 

5.  After  issuing  one  or  more  commands  to  the  RMs,  the  application  informs 
the  TM  that  it  wants  to  commit  its  current  transaction. 

6.  The  TM  makes  an  xa: prepare  call  to  each  of  the  RMs.  Each  RM  returns 
a  value  indicating  that  it  is  ready  to  commit. 

7.  The  TM  makes  an  xa:  commit  call  to  each  of  the  RMs,  indicating  that  it 
should  commit  its  work. 

The  ax  subservice  is  used  by  the  RMs  to  dynamically  register  with  the  TM. 
Once  an  RM  registers  with  the  TM,  it  is  then  managed  along  with  all  the  other 
RMs  that  the  TM  currently  knows  about.  This  feature  is  intended  to  permit 
RMs  that  are  infrequently  used  to  be  managed  only  when  they  are  doing  actua 
work,  thus  avoiding  the  necessity  for  them  to  engage  in  the  transaction  protocol 
when  they  aren’t  processing  transactions. 
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7,7.3  The  AR  Service 


The  AR  service  is  the  service  an  RM  provides  to  allow  applications  to  access 
its  shared  resources.  The  X/Open  DTP  standard  does  not  specify  the  form 
this  interface  must  take.  It  allows  the  RMs  to  provide  standard  interfaces,  such 
as  SQL,  and/or  custom  or  proprietary  interfaces.  The  SDTP  RM  reference 
implementation  currently  provides  a  custom  interface  built  on  top  of  SQL. 

A  typical  call  to  an  AR  service  looks  like  the  following: 

(wire : remote-value 
rm-wire 

(ar: update  *tid* 

(encrypt-string  "inv.id”  common-key) 

(encrypt-string  new-inv-id  common-key) 

(encrypt-string  "  "  common-key) 

(encrypt-string  "  "  common-key))) 

where  rm-wire  is  the  wire  or  connection  the  application  has  to  the  resource 
manager,  ar: update  is  the  actual  RPC  to  the  AR  service,  ♦tid*  is  the  appli¬ 
cation’s  thread  ID  and  the  rest  of  the  arguments  are  mapped  into  an  update 
SQL  statement. 

The  SDTP  reference  implementation  of  the  AR  service  uses  encryption  to 
secure  the  contents  of  its  network  communications  (as  do  the  other  services). 
The  current  encryption  package  uses  a  Diffie- Heilman  key  exchange  protocol 
and  RC4  as  its  encryption  mechanism. 

7.8  Cooperating  Law  Enforcement  Databases 

As  a  test  application  for  the  SDTP  reference  implementation,  we  built  an  MLS 
law  enforcement  tracking  system.  This  system  was  inspired  by  an  FBI  sys¬ 
tem  called  “FOIMS”  (Field  Office  Information  Management  System),  though  of 
course  it  bears  no  relationship  to  the  actual  working  of  that  system. 

Our  intent  in  building  this  application  was  to  demonstrate  multilevel  security 
in  a  database  system  that  was  both  distributed  and  replicated.  For  this  reason 
we  decided  to  distribute  the  information  for  state  investigations  and  replicate 
the  federal  information.  The  motivation  for  this  was  that  each  state  would  tend 
to  query  and  update  its  own  information  the  vast  majority  of  the  time  and  so 
it  would  be  more  efficient  to  keep  that  information  on  local  resource  managers 
and  allow  remote  queries;  on  the  other  hand,  federal  information  would  likely 
be  queried  by  many  states  and  so  it  would  be  more  efficient  to  replicate  that 
information  across  the  resource  managers  belonging  to  the  states. 

An  example  of  a  table  that  contains  information  classified  at  varying  security 
levels  was  the  agent  table.  This  table  contained  a  unique  ID  number  for  each 
agent  as  well  as  the  agent’s  name.  The  ID  number  was  needed  at  all  security 
levels,  both  to  keep  track  of  agent  workloads  and  to  ensure  that  each  investiga¬ 
tion  had  a  valid  agent  assigned  to  it.  However,  the  agent’s  name  was  considered 


top  secret  and  so  it  was  available  only  when  the  user  making  the  query  was 
authenticated  at  the  top  secret  security  level. 

Other  examples  of  multilevel  tables  are  the  investigation  tables.  Each  inves¬ 
tigation  was  classified  at  a  particular  security  level;  even  the  fact  that  an  inves¬ 
tigation  was  being  conducted  on  a  particular  individual  might  itself  be  sensitive 
information.  For  this  reason,  investigations  that  might  have,  for  example,  im¬ 
portant  political  implications  were  classified  top  secret,  while  investigations  that 
had  resulted  in  court  cases  would  ordinarily  be  public  knowledge  and  therefore 
unclassified. 

Our  demonstration  implementation  contained  resource  managers  for  two 
states,  each  of  which  also  contained  a  replica  of  the  federal  portion  of  the 
database.  The  application  was  capable  of  querying,  updating,  and  adding  in¬ 
formation  to  the  relevant  tables. 

The  SDTP  reference  architecture  enforces  the  simple  security  property  {no 
read-up)  and  the  ^-property  {no  write-down)  by  using  a  distributed  Security 
Manager  layer.  These  Security  Managers  each  used  a  set  of  single-level  databases 
for  storage;  the  combination  of  the  Security  Manager  layer  and  the  single-level 
databases  produced  a  virtual  multilevel  resource  manager. 

The  Security  Managers  communicated  with  the  single-level  databases  by 
using  the  native  interface  provided  by  the  database.  The  Security  Manager 
would  create  a  set  of  communication  links  to  the  databases  and  manage  them 
so  as  to  maintain  the  security  constraints.  When  an  operation  was  requested 
by  a  component,  the  Security  Manager  would  select  the  set  of  links  that  were 
appropriate  for  that  operation.  For  example,  when  a  component  requested  a 
read  operation,  the  Security  Manager  would  select  the  links  to  databases  serving 
the  current  security  level  or  lower.  A  write  operation  would  result  in  only  the 
current  security  level’s  link  being  selected. 

The  screen  dump  in  Figure  7.6  shows  the  demonstration  instance  in  opera¬ 
tion. 


7.9  Related  Work 

A  great  deal  of  work  has  been  devoted  to  transformational  development  of  soft¬ 
ware  artifacts  and  to  (informal)  architecture  refinement,  but  very  little  has  been 
done  that  combines  both.  Other  than  our  own  papers  on  the  subject,  some  of 
the  best  examples  are  Brinksma,  Jonsson,  and  Orava  s  work  on  connector  re¬ 
finement  [3],  work  on  component  refinement  [4],  and  Philipps  and  Rumpe’s  work 
on  refinement  of  information  flow  architectures  [35].  However,  work  on  relat¬ 
ing  models  of  connector  behavior  at  different  levels  of  abstraction  by  Abowd, 
Allen,  and  Garlan  [1],  Luckham,  et  al.  [19],  and  Moriconi  and  Qian  [25]  is  closely 
related. 

Similarly,  a  great  deal  of  work  has  been  devoted  to  developing  verification 
of  transformations,  but  we  are  unaware  of  any  work  specifically  devoted  to  de¬ 
veloping  techniques  for  showing  that  transformations  always  introduce  faithful 
interpretations  other  than  our  own,  with  the  exception  of  the  sort  of  very  gen- 
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Figure  7.6:  SDTP  Demonstration  Instance  in  Operation 
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eral  techniques  for  proving  the  existence  of  faithful  interpretations  found  in 
references  such  as  Turski  and  Maibaum’s  book  [45]. 

Generally  speaking,  the  security  community  has  not  been  successful  in  for¬ 
mally  linking  security  proofs  to  actual  implementations.  A  notable  exception  is 
Neely  and  Freeman’s  verification  of  a  secure  gateway  [33,  34].  The  technique 
used  in  Neely  and  FVeemen’s  case  study  is  not  adequate  to  deal  with  the  SDTP 
architecture,  because  it  treats  only  horizontal  refinement  (i.e.,  “bubble  decom¬ 
position”)  and  not  vertical  refinement  (i.e.,  change  in  style  of  representation). 

7.10  Chapter  Summary 

The  SDTP  ceise  study  was  performed  with  several  objectives  in  mind.  First, 
we  wanted  to  determine  whether  implementation-level  SDTP  architectural  de¬ 
scriptions  could  be  derived  for  the  three  implementation  approaches  defined 
in  our  earlier  paper  [27]  by  the  application  of  transformations  that  introduce 
only  faithful  interpretations.  While  we  do  not  have  a  definitive  answer  to  this 
question,  our  experience  suggests  that  such  a  derivation  would  be  difficult  or  im¬ 
possible.  Therefore,  we  attempted  to  determine  whether  implementations  could 
be  derived  using  only  transformations  that  always  preserve  security.  The  an¬ 
swer  to  this  question  is  certainly  yes.  But  we  discovered  that  defining  generally 
useful  transformations  that  always  preserve  security  can  be  quite  difficult,  in 
some  cases.  Preservation  of  security  sometimes  requires  the  addition  of  strong 
preconditions  to  the  transformation.  These  strong  preconditions  can  seriously 
reduce  the  transformation’s  generality.  We  therefore  developed  an  alternative 
approach  allowing  transformations  that  only  sometimes  preserve  security  to  be 
employed.  Rather  than  building  some  specific  set  of  sufficient  conditions  for  se¬ 
curity  preservation  into  the  transformation,  we  check  whether,  in  each  individual 
application  of  the  transformation,  security  has  been  preserved.  Our  approach 
to  checking  is  based  on  a  notion  we  call  proof- carrying  architectures  [40]:  the 
same  transformation  used  to  implement  the  architectural  description  is  used  to 
“implement”  the  security  proof,  which  is  carried  along  with  the  architectural 
description.  Using  a  combination  of  showing  that  some  transformations  always 
introduce  faithful  interpretations  and  checking  that  the  others  preserve  secu¬ 
rity  in  the  particular  case,  we  succeeded  in  manually  verifying  the  security  of 
all  12  implementation-level  architectural  descriptions  (four  per  implementation 
approach). 

A  second  objective  in  performing  the  case  study  was  to  begin  to  determine 
whether  our  “rearchitecting  via  replay”  model  works  as  well  for  global  architec¬ 
tural  changes  (such  as  introducing  security  requirements)  as  it  has  worked  in 
the  23  small-scale  local  rearchitecting  case  studies  we  have  performed  based  on 
the  X/Open  DTP  architecture,^  As  we  pointed  out  above,  the  X/Open  DTP 
derivation  was  very  effectively  reused  in  the  defining  the  SDTP  hierarchies.  In 

^The  23  studies  are  based  on  making  a  variety  of  small  changes  in  system  requirements  (e.g., 
adding  an  RM)  and/or  implementation  infrastructure  (e.g.,  reducing  the  cost  of  interprocessor 
communication). 
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addition,  our  techniques  for  quickly  estimating  the  cost  of  changes,  and  con¬ 
servatively  bounding  the  scope  of  changes,  required  to  restore  consistency  in 
a  hierarchy  after  a  change  has  been  introduced  continued  to  work  effectively. 
Therefore,  we  have  begun  the  process  of  designing  a  rearchitecting  tool  based 
on  this  model  that  we  believe  will  provide  very  substantial  automated  support 
for  the  process. 

Our  third  objective  in  performing  the  case  study  was  to  assess  the  effective¬ 
ness  of  our  transformation  verification  techniques  on  a  larger  stock  of  transfor¬ 
mations,  Although  we  wound  up  abandoning  the  idea  of  using  only  generally 
valid  transformations  in  the  development  of  the  SDTP  hierarchies,  all  the  trans¬ 
formations  that  we  believe  to  be  generally  valid  were  successfully  verified.  So, 
as  mentioned  above,  we  have  begun  to  explore  the  process  of  automating  these 
manual  verifications  using  SRI’s  PVS  verification  system. 

The  final  principal  objective  was  to  determine  whether  the  lowest  level  archi¬ 
tectural  descriptions  in  the  SDTP  hierarchy  were,  in  fact,  implementation-level. 
In  other  words,  we  wanted  to  confirm  our  belief  that  no  significant  design  deci¬ 
sions  would  have  to  be  made  when  turning  these  low-level  descriptions  into  exe¬ 
cutable  code.  This  is  crucial,  because  the  hierarchy  effectively  links  the  abstract 
architecture  to  the  actual  implementation  only  if  the  gap  between  the  lowest- 
level  description  and  the  code  is  very  small.  If  the  gap  is  too  large,  confidence 
that  the  “implementation-level”  descriptions  of  SDTP  are  secure  provides  only 
weak  evidence  that  the  actual  implementation  is  secure.  Our  experience  was 
that  writing  the  code  from  these  low-level  descriptions  is  completely  straight¬ 
forward,  thanks  to  formalizing  information  about  implementation  language  fa¬ 
cilities  as  Sadl  styles.  Although  this  approach  makes  the  low-level  implemen¬ 
tation  decisions  in  the  SDTP  hierarchies  implementation-language-dependent, 
it  should  hardly  be  surprising  that  choice  of  a  programming  language  for  the 
implementation  affects  low-level  architectural  design.  Designs  appropriate  for 
other  choices  of  programming  language  can  be  included  by  introducing  addi¬ 
tional  branches  in  the  hierarchies  (although  we  have  not  done  so  in  the  case 
of  the  SDTP  hierarchies  we  have  developed).  It  should  be  noted  that  all  these 
branchings  would  be  at  a  level  of  abstraction  lower  than  the  X/Open  standard, 
and  hence  they  do  not  reduce  the  general  utility  of  an  SDTP  standard  at  that 
same  abstraction  level.  Based  on  this  experience,  we  are  planning  to  extend  our 
architecture  transformation  toolset  by  including  a  facility  for  automatic  gener¬ 
ation  of  code  for  the  architecture  from  an  implementation-level  description  in 
Sadl. 

So  it  can  be  seen  that  development  of  the  three  SDTP  hierarchies  and  the 
one  reference  implementation  and  demonstration  instance  served  as  a  useful 
case  study  in 

•  transformational  development  of  architectures, 

•  rearchitecting  after  adding  a  new  “global”  system  requirement, 

•  transformation  verification,  and 

•  linking  architectural  descriptions  to  code. 
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Chapter  8 


The  SDTP  Reference 
Implementation 


8.1  The  SDTP  Architecture 

The  X/Open  DTP  standard  for  distributed  transaction  processing  consists  of  a 
protocol  specification  and  a  set  of  services  that  the  components  of  the  system 
must  make  available  to  other  system  components.  SRFs  DSA  (Dependable 
System  Achitecture)  group  has  used  this  standard  as  a  testbed  for  applying  our 
methods  for  verifying  and  extending  formal  descriptions  of  architectures. 

Our  most  recent  project  in  this  area  involved  extending  the  X/Open  DTP 
standard  to  incorporate  multilevel  security  properties.  This  paper  describes  a 
prototype  reference  implementation  that  implements  this  extended  standard, 
along  with  two  applications  built  using  the  SDTP  system  [27]. 

8.1.1  X/Open  DTP 

The  X/Open  DTP  standard  [47,  49,  48,  46]  is  intended  to  standardize  the  in¬ 
teractions  and  communications  between  the  components  of  the  3-tiered  client- 
server  model  for  distributed  transaction  processing.  It  allows  multiple  applica¬ 
tion  programs  to  share  heterogeneous  resources  provided  by  multiple  resource 
managers  (e.g.,  database  managers,  print  managers)  and  allows  their  work  to 
be  coordinated  into  global  transactions. 

A  version  of  the  X/Open  architecture,  shown  in  Figure  8.1,  consists  of  three 
types  of  components — one  application  program  (AP),  one  transaction  manager 
(TM),  and  one  or  more  resource  managers  (RMs).  The  boxes  indicate  the  com¬ 
ponent  interfaces,  and  the  lines  indicate  the  communications  between  them.  The 
label  TX  indicates  a  complex  connection  and  protocol  defining  communication 
between  any  application  module  and  any  transaction  manager.  This  connection 
contains  communication  channels  between  functions  that  initialize  and  finalize 
transactions.  Communication  is  always  initiated  by  the  application.  A  series  of 
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Figure  8.1:  X/Open  DTP  Reference  Architecture 


calls  back  and  forth  continues  until  communication  is  completed. 

Similar  complex  connections  exist  between  the  application  and  every  re¬ 
source  (the  AR  connection)  and  between  the  transaction  manager  and  every 
resource  manager  (the  XA  connection).  The  XA  connection  provides  communi¬ 
cation  for  the  well-known  two-phase  commit  protocol  that  ensures  the  atomicity 
of  transactions.  Much  of  this  activity  can  be  concurrent,  and  many  transactions 
may  take  place  at  once. 

The  X/Open  standard  talks  about  these  connections  in  terms  of  the  services 
(TX,  AR,  XA)  that  each  component  must  provide  and  the  interface  functions 
that  implement  these  services.  The  TX  service,  also  known  as  the  Transaction 
Demarcation  service,  must  be  provided  by  the  TM.  The  RM  provides  the  AR 
service,  which  is  the  actual  data  storage  interface  to  the  RM.  The  AP  makes 
use  of  the  TX  and  AR  services.  The  XA  service  consists  of  two  subservices,  one 
provided  by  the  TM  and  the  other  provided  by  the  RMs.  The  former,  called 
the  AX  subservice  or  AXS,  allows  RMs  to  dynamically  register  and  unregister 
themselves.  The  latter,  called  the  XA  subservice  or  XAS,  exports  the  procedures 
the  TM  uses  to  coordinate  the  transactions.  Both  the  TX  and  XA  services  are 
fully  specified,  albeit  informally,  while  the  implementation  is  allowed  to  use  a 
custom  set  of  functions  for  the  AR  service,  allowing  implementations  to  build 
custom  resource  managers.  Table  8.1  gives  a  complete  listing  of  the  TX  and  XA 
services, 

8.1.2  Multilevel  Security 

A  standard  model  of  a  multilevel  security  (MLS)  policy  is  the  Bell-LaPadula 
model  [16].  Given  a  set  of  subjects  each  with  an  attached  clearamce  level,  and 
a  set  of  objects  each  with  an  attached  classification  level,  the  model  ensures 
that  information  does  not  fiow  downward  in  a  security  lattice  by  imposing  the 
following  requirements: 
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Name 

TX:BEGIN 

TX:CLOSE 

TXrCOMMIT 

TX:INFO 

TX:OPEN 

TX:ROLLBACK 

TX:SET-COMMIT-RETURN 

TX:SET-TRANSACTION-CONTROL 

TX:SET-TRANSACTION-TIMEOUT 

AXS:REG 

AXS:UNREG 

XAStCLOSE 

XAS;COMMIT 

XAS:END 

XASrOPEN 

XAS-.PREPARE 

XAS:ROLLBACK 

XASiSTART 


Description 

Start  a  new  transaction 

Close  the  resource  managers 

Complete  a  transaction  normally 

Query  the  TM  about  the  status  of  a  transaction 

Open  the  resource  managers 

Abort  a  transaction 

Wait  for  commit  completion  or  just  for  logging 

Indicate  ‘chained’  transactions 

Set  transaction  time  limit 

Let  the  RM  register  itself  with  the  TM 

Let  the  RM  unregister  itself 

Tell  RM  not  to  listen  for  connections  any  more 

Tell  RM  to  commit  the  transaction 

Tell  RM  to  end  a  transaction 

Inform  RM  that  application  is  opening  it 

Ask  RM  if  it  can  commit  the  current  transaction 

Tell  RM  to  abort  the  transaction 

Tell  RM  to  start  a  transaction  for  a  given  apphcation 


Table  8.1:  TX  and  XA  services 


•  The  Simple  Security  Property.  A  subject  is  allowed  a  read  access  to 
an  object  only  if  the  subject’s  clearance  level  is  identical  to  or  higher  than 
the  object’s  classification  level  in  the  lattice. 

•  The  *  Property.  A  subject  is  allowed  a  write  access  to  an  object  only 
if  the  subject’s  clearance  level  is  identical  to  or  lower  than  the  latter’s 
classification  level  in  the  lattice. 

The  MLS  policy  regulates  communication  between  the  application  and  the 
resources.  As  such,  it  is  primarily  a  property  of  the  architectural  structure. 
That  is,  it  specifies  that  an  application  should  not  be  allowed  to  connect  to  a 
resource  manager  that  contains  data  for  which  it  is  not  cleared. 

8.1.3  Secure  DTP 

The  SDTP  implementation  is  based  on  a  specification  generated  by  formaliz¬ 
ing  the  X/Open  DTP  specification  in  Sadl  [28],  the  Architecture  Description 
Language  used  by  our  group,  and  then  adding  the  MLS  properties  to  the  speci¬ 
fication.  The  resulting  specification  was  refined  using  provably  correct  transfor¬ 
mations  until  an  implementable  specification  was  produced.  The  implemented 
architecture  can  be  seen  in  Figure  8.2. 

The  refinement  process  by  which  this  architecture  was  produced  can  be  de¬ 
scribed  as  starting  with  communication  channels  that  enforce  the  multilevel  se¬ 
curity  pohcy,  and  then  refining  them  into  ordinary  communication  channels  with 
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Figure  8.2:  X/Open  DTP  Extended  with  Multilevel  Security 


the  security  policy  enforcement  implemented  by  a  security  manager.  Finally, 
the  security  manager  is  distributed  as  security  wrappers  around  each  resource 
manager.  The  resource  managers  themselves  are  implemented  as  a  collection 
of  single-level  database  managers.  The  resulting  specification  preserves  both 
the  desired  atomicity  properties  of  X/Open  DTP  and  the  security  properties 
mentioned  above. 


8.2  SDTP  System  Components 

One  goal  of  SDTP  was  a  desire  to  be  able  to  install  it  for  our  client  and  poten¬ 
tially  other  interested  parties  without  the  need  to  purchase  expensive  equipment 
and  software  licenses.  For  this  reason,  we  tried  to  use  freely  available  software 
whenever  possible.  It  turned  out  to  be  possible  to  build  the  system  with  all  ma¬ 
jor  software  components  being  in  the  public  domain  or  having  free  redistribution 
licenses.  The  following  components  were  important  in  building  SDTP: 

•  FreeBSD.  We  chose  the  FreeBSD  operating  system  because  we  were  ex¬ 
perienced  with  it  and  had  found  it  reliable  in  the  past.  It  runs  on  inexpen¬ 
sive  Intel-x86  hardware  and  has  a  wide  variety  of  freely  available  software, 
including  database  software  and  Lisp  implementations,  available  through 
its  ‘ports’  packaging  system.  In  many  cases,  a  desired  software  package 
can  be  installed  by  finding  the  appropriate  ‘ports’  directory  and  issuing 
a  ‘make  install’  command.  We  found  it  more  stable  and  less  of  a  moving 
target  than  Linux,  another  freely  available  UNIX-like  operating  system. 


114 


•  CMU  Common  Lisp.  The  CMU  version  of  Common  Lisp  [43]  is  a  high- 
quality  Lisp  implementation  that  is  in  the  public  domain.  We  have  found 
its  performance  to  be  mostly  competitive  with,  and  occasionally  better 
than,  commercial  implementations.  Its  compiler  also  provides  informative 
optimization  notes  that  guide  the  programmer  in  making  declarations  that 
improve  performance. 

•  Common  Lisp  Bignum  Facility  To  provide  secure  communications 
channels,  we  encrypted  the  data  objects  that  were  sent  over  them.  To  do 
this,  we  had  to  implement  key  exchange  and  encryption.  Common  Lisp’s 
bignum  facility  turned  out  to  be  extremely  convenient  for  this  purpose. 

For  example,  Diffie-Hellman  key  exchange  involved  three  functions  that 
were  each  essentially  one  line  of  code  (omitting  declarations),  along  with 
a  ‘modpower’  function  ![42]: 

;;;  Modpower  function  from  clmath  package  by  Gerald  Roy lance. 

(def\m  modpower  (number  exponent  modulus) 

(declare  (integer  number  exponent  modulus)) 

(do  ((exp  exponent  (floor  exp  2)) 

(sqr  number  (mod  (*  sqr  sqr)  modulus)) 

(ans  1)) 

((zerop  exp)  ans) 

(declare  (integer  exp  sqr  ans)) 

(if  (oddp  exp) 

(setq  ans  (mod  (*  ans  sqr)  modulus))))) 

(defun  compute- secret -key  (dh-modulus) 

(declare  (integer  dh-modulus)) 

(random  dh-modulus  (make-random-state  t))) 

(defun  compute-public-key  (base  secret-key  modulus) 

(declare  (integer  base  secret-key  modulus)) 

(modpower  base  secret-key  modulus)) 

(defun  compute-common-key  (remote-public-key 

local-secret-key 

modulus) 

(declare  (integer  remote-public-key 
local-secret-key 
modulus) ) 

(modpower  remote-public-key  local-secret-key  modulus)) 

While  researching  implementations  we  found  a  version  written  in  the  C 
programming  language  that  took  about  90  lines.  Much  of  the  C  code  in¬ 
volved  processing  a  set  of  arrays,  which  in  effect  implemented  a  bignum 
capability.  As  a  result,  the  connection  between  the  C  code  and  the  al¬ 
gorithm  being  implemented  was  tenuous,  while  the  Lisp  code  above  is 
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a  direct  implementation  of  the  algorithm.  The  bignum  facility  was  also 
useful  in  the  actual  encryption  and  decryption  of  data,  allowing  us  to 
represent  intermediate  forms  of  the  encrypted  data  as  integers. 

•  PostgreSQL.  We  used  the  PostgreSQL[36]  relational  database  manager 
to  provide  data  storage  management  for  SDTP.  The  choice  of  PostgreSQL 
was  based  on  the  fact  that  we  had  previous  experience  with  it,  it  wcts  easy 
to  install  and  run,  and  it  was  licensed  so  as  to  allow  us  to  distribute  it 
conveniently. 

PostgreSQL  comes  with  programmatic  interfaces  for  several  languages; 
unfortunately  Lisp  was  not  one  of  them.  As  a  result  we  had  to  develop  a 
Lisp  interface  to  PostgreSQL. 

There  are  at  least  two  ways  to  implement  such  an  interface.  One  way 
is  to  talk  directly  to  the  PostgreSQL  back  end  over  the  network.  This 
involved  creating  packets  and  sending  them  to  the  back  end.  Since  at  the 
time  we  were  not  completely  sure  how  this  worked,  we  decided  to  take 
the  second  approach,  which  involved  writing  a  foreign- function  interface 
to  the  C  version  of  the  PosgreSQL  client  library. 

Like  other  Common  Lisp  implementations,  CMU  Common  Lisp  has  a 
package  that  allows  Lisp  code  to  talk  to  code  written  in  C.  Interfacing  to 
the  PostgreSQL  library  involved  writing  a  file  of  interface  functions  using 
the  CMUCL  Foreign  Function  Interface.  It  turned  out  to  be  easy  to  write 
the  code.  There  were  a  few  opaque  data  structures,  some  enumerations 
for  status  returns,  and  a  series  of  functions.  The  following  is  a  sample  of 
the  code 

;;  Opaque  data  structures. 

(def-alien-type  postgres-connection  system-area-pointer) 

(def -alien-type  postgres-result  system-area-pointer) 

;;  Status  enumerations. 

(def-alien-type  connection-status  (enum  nil 

: connection-ok 
: connection-bad) ) 


(def-alien-type  exec-status  (enum  nil 

(: empty-query  0) 
:  commsind-ok 
:tuples“Ok 
: copy-out 
: copy- in 
: bad-response 
; nonf atal-error 
: fatal-error) ) 
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;;  Some  of  the  actual  library  interface  functions. 

(declaim  (inline  PQsetdbLogin) ) 

(def-alien-routine  "PQsetdbLogin"  postgres-connection 
(pghost  c-string) 

(pgport  c-string) 

(pgoptions  c-string) 

(pgtty  c-string) 

(dbname  c-string) 

(login  c-string) 

(passwd  c-string)) 

(declaim  (inline  PQexec)) 

(def-alien-routine  "PQexec"  postgres-result 
(connection  postgres-connection) 

(command  c-string)) 

(declaim  (inline  PQresultStatus) ) 

(def-alien-routine  "PQresultStatus"  exec-status 
(result  postgres-result)) 

(declaim  (inline  PQntuples)) 

(def-alien-routine  "PQntuples"  int 
(result  postgres-result)) 

(declaim  (inline  PQnfields)) 

(def-alien-routine  "PQnfields"  int 
(result  postgres-result)) 

;;  etc. 

A  couple  of  problems  arose  from  using  this  method.  The  main  problem 
was  due  to  an  interaction  between  FreeBSD’s  object  format  and  CMUCL. 
CMUCL  is  currently  linked  statically  under  FreeBSD,  which  means  it 
cannot  use  shared  binary  objects.  The  PostgreSQL  C  library  is  built 
using  shared  objects,  for  both  its  shared  and  static  versions.  (We  think 
this  is  a  bug  but  were  unable  to  convince  the  maintainers  to  change  it.)  At 
any  rate,  we  were  forced  to  create  by  hand  a  library  using  static  objects. 

A  similar  problem  involved  the  process  of  actually  loading  the  library  into 
the  running  Lisp.  Since  CMUCL  running  under  FreeBSD  uses  an  old 
technique  of  runtime  linking,  rather  than  the  newer  technique  of  dynamic 
loading,  the  C  code  library  can  be  loaded  only  once  per  session;  multiple 
loadings  result  in  multiple  definition  errors. 

•  Remote  Procedure  Call,  SDTP  is  implemented  as  a  set  of  components 
and  communication  facilities.  Our  desire  was  to  try  to  reflect  current 
practice  in  implementing  a  DTP  system.  Thus,  communication  between 
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the  components  is  done  using  a  Lisp-based  Remote  Procedure  Call  (RPC) 
mechanism. 

The  components  of  SDTP  employ  a  Lisp-based  RPC  mechanism  for  all 
communication  except  the  communication  with  the  database  managers 
(which  is  done  through  the  programmatic  interface  library  discussed  above) 
The  RPC  mechanism  used  is  the  Remote  package  provided  by  CMU  Lisp. 
It  is  built  on  a  lower-level  socket  based  package  called  the  Wire  package. 
The  Remote  package  allows  calls  like  the  following; 

(wire remote-value  rm-wire  (xas:open  tmid  rmid  flags)) 

where  rm-wire  is  a  handle  on  the  communication  link  over  which  the  call 
is  being  made.  This  call  causes  the 

(xas:open  tmid  rmid  flags) 

procedure  call  to  be  evaluated  in  the  remote  Lisp  process  referenced  by 
the  rm-wire  handle. 

The  Remote  package  has  several  limitations.  First,  it  is  limited  in  the 
data  objects  it  can  actually  send  between  the  communicating  processes. 
It  lacks  a  fully  general  external  data  representation  (XDR)  mechanism. 
On  the  other  hand,  it  allows  a  remote  Lisp  process  to  refer  to  a  local 
data  structure  by  passing  a  token  called  a  remote  object.  The  remote 
process  can,  without  actually  modifying  the  data  object,  effectively  pass 
it  back  as  a  return  value  or  pass  it  as  a  parameter  to  a  call-back  procedure 
it  invokes  in  the  local  process.  Communicationds  channels  created  by 
the  Remote  package  are  bidirectional;  a  remote  Lisp  process  can  invoke 
procedures  in  the  local  process  as  well  as  the  other  way  around.  If  a 
process  needs  to  actually  send  data  objects  that  are  not  supported  by  the 
Remote  package,  it  must  convert  them  to  a  string  format  and  send  them 
as  strings,  whereupon  the  remote  process  must  convert  them  back  into 
data  objects.  In  practice,  limitations  of  data  object  types  did  not  arise  in 
this  system. 

Another  limitation  was  the  fact  that  the  Remote  package  provided  no  ac¬ 
cess  control.  A  process  making  remote  procedure  calls  can  invoke  any  pro¬ 
cedure  in  the  remote  Lisp  process,  if  it  knows  the  package  and  procedure 
name.  This  creates  a  security  hole;  at  the  very  least  a  malicious  client 
could  invoke  a  denial-of-service  attack  by  remotely  calling  the  (quit) 
procedure.  It  would  be  fairly  straightforward  to  create  a  version  of  the 
Remote  package  that  required  each  process  to  register  procedures  that  it 
would  allow  to  be  invoked  remotely;  such  an  extension  was  not  made  in 
this  implementation  but  will  probably  be  done  in  the  future. 

•  Graphical  User  Interface  Toolkit.  At  first,  SDTP  did  not  have  a  GUI. 
In  the  form  we  originally  demonstrated,  it  had  a  graphical  display  to  show 
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Figure  8.3:  SDTP  with  Component  Interaction  Graph 

the  interactions  between  the  components  (see  Figure  8.3).  To  make  the 
demonstration  application  more  usable,  we  decided  to  give  it  a  GUI.  All 
the  GUI  work  in  SDTP,  including  the  component-interaction  graph,  was 
done  using  the  Garnet  [9]  toolkit. 

The  Garnet  toolkit,  besides  being  freely  distributable,  had  good  perfor¬ 
mance  and  a  relatively  small  footprint  in  CMUCL.  An  x86  Lisp  image 
with  Garnet  is  about  18  MB,  while  the  image  without  Garnet  is  about  14 
MB  (CMUCL’s  images  are  considerably  larger  than  current  commercial 
versions).  This  compares  to  a  size  of  around  28  MB  for  a  CLOS-based 
toolkit  such  as  XIT/CLUE  [14]. 

Originally  we  were  concerned  about  the  fact  that  Garnet  did  not  use  CLOS 
as  its  object  system;  instead  it  uses  KR,  a  relatively  simple  prototype- 
instance  object  system  with  constraints.  However,  with  experience  we 
came  to  feel  that  KR’s  approach  was  a  good  match  for  GUI  development, 
and  its  (relatively)  small  size  and  low  overhead  served  us  well  when  we  in¬ 
stalled  the  system  on  laptops  and  other  resource-limited  machines.  At  one 
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point  we  had  several  Lisp  processes,  including  a  Garnet  process,  running 
on  a  32  MB  200  MHz  Pentium  machine.  Performance,  while  not  sterling, 
was  adequate.  CMUCL  uses  the  PCL  version  of  CLOS.  Experience  with 
the  XIT  toolkit  showed  that  it  caused  PCL  to  spend  a  lot  of  time  doing 
runtime  compilation,  especially  when  it  loaded  files,  while  Garnet  did  little 
or  no  runtime  compilation. 

Among  Garnet’s  important  features  that  we  used  heavily  were  objects 
known  as  ‘interactors’  that  deal  with  various  types  of  user  input.  Interac- 
tors  can  be  attached  to  different  graphical  objects,  thus  almost  completely 
decoupling  the  look  of  the  object  from  the  way  the  object  responds  to 
user  interaction.  As  a  result  of  the  use  of  interactor  objects,  Garnet  al¬ 
lows  a  programming  style  that  minimizes  the  use  of  callbacks.  Instead  of 
an  event-driven  model  where  the  programmer  writes  procedures  that  are 
given  control  in  response  to  user  actions,  the  programmer  can  use  a  more 
functional  approach.  We  ended  up  in  effect  calling  the  GUI  as  a  function 
that  returns  the  results  of  the  user’s  activity.  The  messy  event  handling 
and  synchronization  is  kept  neatly  behind  the  scenes  by  the  interactor 
mechanism. 

Garnet  provides  two  toolkits  with  different  appearances.  We  used  both; 
for  the  component-interaction  graph  we  used  Garnet’s  native  toolkit,  while 
for  the  application  GUIs  we  used  the  second  toolkit  that  provides  a  Motif¬ 
like  appearance. 


8.3  Applications 

We  built  two  applications  on  top  of  SDTP.  The  first  is  a  demonstration  appli¬ 
cation  used  to  show  that  SDTP  works  and  has  the  desired  security  properties. 
The  second  is  intended  as  the  genesis  of  a  real-world  application  that  would 
serve  as  an  intelligent  post-processor  to  a  computer  intrusion-detection  system. 
Figure  8.4  illustrates  the  GUI  style  of  both  applications. 

8.3.1  Cooperating  Law  Enforcement  Databases 

As  a  test  application  we  built  a  multilevel-secure  law-enforcement-tracking  data¬ 
base,  LET-DB.  This  was  inspired  by  an  FBI  system  called  “FOIMS”  (Field  Of¬ 
fice  Information  Management  System),  though  of  course  it  bears  no  relationship 
to  the  actual  working  of  that  system. 

Our  intent  in  building  this  application  was  to  demonstrate  multilevel  security 
in  a  database  system  that  was  both  distributed  and  replicated.  For  this  reason 
we  decided  to  distribute  the  information  for  state  investigations  and  replicate 
the  federal  information.  The  motivation  for  this  was  that  each  state  would  tend 
to  query  and  update  its  own  information  the  vast  majority  of  the  time  and  so 
it  would  be  more  efficient  to  keep  that  information  on  local  resource  managers 
and  allow  remote  queries;  on  the  other  hand,  federal  information  would  probably 
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Figure  8.4;  SDTP  Application  GUI 


be  queried  by  many  states  and  so  it  would  be  more  efficient  to  replicate  that 
information  across  the  resource  managers  belonging  to  the  states. 

An  example  of  a  table  that  depended  on  multilevel  security  was  the  agent 
table.  This  table  contained  a  unique  ID  number  for  each  agent  as  well  as  the 
agent’s  name.  The  ID  number  was  needed  at  all  security  levels,  both  to  keep 
track  of  agent  workloads  and  to  ensure  that  each  investigation  had  a  valid  agent 
assigned  to  it.  However,  the  agent’s  name  was  considered  top  secret  and  so  it 
was  available  only  when  the  user  making  the  query  was  authenticated  at  the 
top  secret  security  level. 

Other  examples  of  multilevel  tables  were  the  investigation  tables  themselves. 
Each  investigation  was  classified  at  a  particular  security  level;  even  the  fact  that 
an  investigation  was  being  conducted  on  a  particular  individual  might  itself  be 
sensitive  information.  For  this  reason,  investigations  that  might  have,  for  ex¬ 
ample,  important  political  implications  were  classified  top  secret,  while  investi¬ 
gations  that  had  resulted  in  court  cases  would  ordinarily  be  public  knowledge 
and  therefore  unclassified. 

Our  demonstration  implementation  contained  resource  managers  for  two 
states,  each  of  which  also  contained  a  replica  of  the  federal  portion  of  the 
database.  The  application  was  capable  of  querying,  updating,  and  adding  in¬ 
formation  to  the  relevant  tables. 

8.3.2  Intrusion  Detection  Application 

The  second  application  built  on  SDTP  is  the  Intrusion  Detection  Application. 
One  of  the  authors  of  this  paper,  David  Shih,  was  hired  as  a  summer  intern  to 
write  this  application.  He  has  completed  his  first  year  as  a  Computer  Science 
major  at  the  University  of  California  at  Berkeley.  His  most  significant  program¬ 
ming  experience  was  his  first-semester  computer  science  programming  course, 
taught  using  Scheme.  Thus  he,  like  the  other  author,  was  writing  his  first  major 
Lisp  program. 

The  Intrusion  Detection  Application  turned  out  to  be  larger  and  more  com¬ 
plex  than  the  Law  Enforcement  Tracking  application.  Like  the  LET-DB  applica¬ 
tion,  the  IRDB  (Intrusion  Recording  Database)  also  manages  multilevel  secure 
databases,  this  time  containing  computer  intrusion  data.  This  application  re¬ 
ceives,  from  one  or  more  secure  sources,  CISL  (Common  Intrusion  Specification 
Language)  data.  CISL  is  a  proposed  standard  for  representing  and  exchanging 
computer  intrusion  data.  A  complete  draft  on  CISL  and  its  syntax  can  be  found 
at 

http : //gost . isi.edu/projects/crisis/cidf/cisl_current.txt . 

Conveniently,  CISL  uses  an  s-expression  format  for  its  external  representation. 

In  our  case,  the  application  receives  CISL  data  describing  intrusion  attempts 
against  machines  located  at  various  military  installations.  (For  example,  our 
current  demonstration  pretends  to  receive  data  from  two,  Ellsworth  AFB  and 
NAB  Coronado).  The  application  currently  reads  CISL  data,  classifies  each 
entry,  and  inserts  the  entry  into  the  proper  database.  A  user  can  then  query 
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the  database,  retrieve  CISL  entries,  and  look  through  an  entry  in  detail  in  a 
more  user-friendly  environment.  Eventually  the  application  will  perform  intelli¬ 
gent  pattern-matching  across  the  database  entries  to  check  for  clues  that  would 
suggest  a  serious  breach  attempt  against  the  network 

Represented  as  s-expressions  in  a  tree  structure,  CISL  attack  entries  express 
specific  information  about  intrusion  attempts  by  describing  the  verb/action  (in 
this  case.  Attack)  with  a  sublayer  of  role  and  adverb  entries.  These  describe  the 
“players”  involved  and  attributes  of  the  verb,  respectively.  Beneath  role  entries 
are  attribute  entries  describing  role  attributes  such  as  the  owner  or  developer 
of  that  particular  player.  All  these  entries — verb,  role,  adverb,  and  attribute 
contain  what  are  known  as  atomic  entries.  An  atomic  entry  contains  the  actual 
values  which  describe  the  entry  within  which  it  is  enclosed.  So  a  sample  generic 
structure  for  a  CISL  entry  could  look  something  like 

(Attack  ;  verb  SID  (semantic  identifier) 

(World  Redhat-5.1)  ;  atomic  SID  and  value 

(Outcome  J  adverb  SID 

(atomSID2  value2) 

(atomSIDS  valueS) ) 

(Observer  »  role  SID 

(atomSID4  value4) 

(atomSIDS  valueS) 

(Owner  *  attribute  SID 

(atomSID6  value6)))) 

Currently,  to  store  data,  a  batch-mode  data-storage  application  simulates 
the  remote  data  streams  that  we  plan  to  use.  Since  the  CISL  data  we  read 
has  no  provision  for  classification  of  records,  the  batch-mode  program  reads  the 
input  and  classifies  the  data.  To  do  this,  it  performs  a  tree  search  for  the  atomic 
field  containing  the  IP  of  the  targeted  machine.  From  the  IP,  it  determines  the 
record’s  security  classification  and  location.  The  intuition  behind  this  is  that 
there  may  be  sensitive  information  exposed  by  an  intrusion  attempt  such  as 
an  unaddressed  vulnerability  of  a  classified  machine,  or  even  the  existence  of 
said  machine — that  users  below  a  certain  security  level  should  not  have  access 
to.  By  classifying  records  by  target  IPs,  records  about  these  machines  can  be 
hidden  away  at  the  proper  level.  Eventually,  however,  instead  of  receiving  data 
from  a  single  mixed  data  stream  and  having  the  application  organize  the  data 
into  different  classification  levels,  the  application  will  receive  information  from 
pre-classified  data  streams,  allowing  the  application  to  simply  tag  the  data  with 
the  security  level  associated  with  the  stream  from  which  it  was  received,  and 
insert  it  into  the  proper  database. 

As  mentioned  above,  input  into  IRDB  can  be  given  only  through  a  secure 
data  stream  containing  raw  CISL  data.  The  application  then  has  to  parse  the 
CISL  s-expressions  into  string  entries  that  can  be  stored  into  the  PostgreSQL 
database.  Because  CISL  was  designed  to  be  extensible,  insertion  of  CISL  s- 
expressions  into  a  relational  database  becomes  a  chore  because  there  is  no  guar¬ 
anteed  uniformity  between  one  CISL  entry  and  the  next.  Atomic  fields  and 
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sub-rows  that  existed  in  one  CISL  construct  may  not  exist  in  another.  As  a  re¬ 
sult,  the  application  has  to  make  sure  that  existing  atomic  fields  that  w^ere  not 
reported  in  a  CISL  entry  are  filled  in  with  some  kind  of  no-data  identifier  and 
that  role  entries  and  adverb  entries  to  the  attack  entry  have  a  similar  procedure 
applied  to  them  and  to  their  attribute  entries.  These  new  “completed”  rows, 
which  now  all  contain  the  same  of  number  entries,  are  then  inserted  into  their 
respective  tables. 

Consequently,  because  of  the  layered  makeup  and  the  potentially  large  size 
of  a  CISL  entry,  it  seemed  more  sensible  to  break  up  the  large  CISL  entry 
into  its  verb,  role  and  adverb  entries  and  insert  each  of  those  entries  into  its 
own  separate  table  rather  than  create  a  table  with  more  than  200  columns. 
To  maintain  uniformity  across  the  multiple  tables,  the  application  tags  each 
subentry  with  a  unique  ID  number.  In  dealing  with  the  attribute  entries,  each 
role  entry  that  allows  for  attribute  entries  has  columns  in  its  table  reserved  for 
each  attribute.  The  application  then  simply  inserts  attribute  entries  in  their 
s-expression  form  as  a  whole  into  the  column  within  the  role  table  to  which 
they  belong.  Since  all  attribute  entries  do  actually  have  the  same  number  and 
type  of  fields,  it  didn’t  seem  necessary  to  create  sixteen  extra  tables  just  to  store 
them.  Instead,  we  use  the  process  described  above  and  employ  a  kind  of  lazy 
procedure  to  format  the  attribute  entry  from  s-expression  to  string  when  the 
user  actually  asks  that  a  particular  attribute  item  be  shown  in  detail  after  the 
query  results  are  displayed  during  lookup. 


8.4  Chapter  Summary 

Both  authors  of  the  applications  were  writing  their  first  major  Lisp  program. 
One  has  more  than  fifteen  years  of  programming  experience  in  everything  from 
assembly  language  and  microprocessor  BASIC  to  C;  the  other  was  writing  his 
first  major  program  in  any  language.  Both  programmers  were  pleased  with  Lisp 
as  part  of  a  development  infrastructure. 

A  major  feature  of  our  development  experience  was  the  interactive  program¬ 
ming  environment.  We  used  the  Ilisp  mode  for  Emacs,  which  gave  convenient 
access  to  the  interactive  features  of  Lisp. 

This  took  getting  used  to.  One  of  us,  used  to  the  C  batch-mode  development 
environment,  found  himself  constantly  killing  off  the  Lisp  process  and  restarting 
it  every  time  he  made  a  change.  Eventually,  it  dawned  on  him  that  it  wasn’t 
necessary  to  do  this.  It  was  a  revelation  when  he  modified  the  text  of  a  func¬ 
tion  and,  using  the  Ilisp  (compile-defun-and-go)  command,  added  it  to  the 
currently  running  system  and  saw  the  change  take  immediate  effect.  This  was 
especially  helpful  because,  upon  restarting  the  system,  it  often  took  a  minute 
or  so  to  get  back  to  the  point  where  the  change  could  be  tested. 

Another  instance  where  the  interactivity  of  Lisp  was  valuable  was  at  the 
conference  where  the  system  was  first  demonstrated.  The  demonstrator  made 
a  typo  that  caught  a  bug  in  the  application.  This  resulted  in  the  application 
entering  the  Lisp  debugger  with  a  segmentation  violation  error.  (This  error 
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indicates  that  the  process  has  made  an  invalid  memory  access,  for  example,  to 
an  area  of  memory  that  is  not  currently  part  of  its  valid  address  space.)  The 
demonstrator  quit  the  debugger,  getting  back  to  the  Lisp  toplevel,  and  then 
re-entered  the  main  loop  of  the  application  and  picked  up  where  he  left  off. 
The  total  time  consumed  by  the  crash  was  about  ten  seconds,  and  it  appeared 
that  the  person  watching  the  demo  didn’t  actually  know  that  the  system  had 
crashed.  This  is  in  contrast  to  the  chaos  that  would  have  resulted  if  an  equivalent 
C  program  had  gotten  a  segmentation  violation. 

The  component-visualization  grapher  turned  out  to  be  an  extremely  effec¬ 
tive  part  of  the  demo,  helping  people  understand  the  interactions  between  the 
components  of  the  system.  It  gave  a  real-time  view  of  what  was  going  on  in  the 
system  and  made  it  clear  how  the  multilevel  security  aspects  operated.  This 
grapher  was  written  using  Garnet  and  was  easy  to  implement  and  test. 

We  have  already  described  the  major  enhancements  and  additions  we  made 
to  the  system — adding  a  GUI  to  the  original  application  and  writing  a  second 
application.  As  we  mentioned  above,  the  task  of  adding  a  GUI  to  a  command- 
line-oriented  application  was  simplified  by  the  programming  style  allowed  by 
the  Garnet  toolkit.  Instead  of  having  to  turn  the  program  flow  inside  out  to 
conform  to  the  event-driven  model  of  typical  X-based  GUI  toolkits,  we  were  able 
to  use  a  functional  approach  that  retained  the  original  program  flow.  Below  is 
part  of  the  main  loop  of  the  application.  The  main  change  from  the  original 
text-based  UI  is  the  use  of  the  calls  to  the  SG  (SDTP-GUI)  package  instead  of  • 
using  text-based  alternatives, 

(defun  do-application  () 

(loop 

(let’*'  ((user  (if  ’•'resource-managers’*' 

(rm-data-user  (cax  ’♦‘resource-managers’*')) 
nil)) 

(command  (sg: application-interface 
user 

(if  (minusp  ’*' current- level ’•') 

11  n 

(level-number-to-naune  ’•‘current-level’*')  )  ) )  ) 
(sg: toplevel-message  "Please  choose  a  menu  item.*') 

(case  command 
( : login 

( setup-tm-connect ion) 

(setup-rms) 

(login)) 

(:quit  J  Logout  and  close  GUI. 

(shutdown) 

(sg: force-quit) 

(return-from  do-application  nil)) 

;;  etc 
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In  general,  we  found  that  the  use  of  Lisp  made  programming  the  system 
a  pleasant  experience.  We  were  able  to  use  a  wide  variety  of  solutions  to  the 
various  problems  the  system  posed  without  fear  that  debugging  new  approaches 
would  be  a  tedious,  time-consuming  process.  Both  developers  learned  new  pro¬ 
gramming  techniques  as  a  result  of  building  this  system.  Most  important,  our 
superiors  and  clients  were  impressed  with  the  results  of  what  we  produced. 
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